#1070494 ITP: linux-livepatching -- linux livepatching module for Debian

Package:
wnpp
Source:
wnpp
Submitter:
Santiago Ruano Rincón
Date:
2025-11-29 16:55:00 UTC
Severity:
normal
#1070494#5
Date:
2024-05-06 11:43:13 UTC
From:
To:
* Package name    : linux-livepatching
  Version         : 0.0.1
  Upstream Contact: Emmanuel Arias <eamanu@debian.org>, Santiago Ruano Rincón <santiago@debian.org>
* URL             : https://salsa.debian.org/debian/linux-livepatching
* License         : GPL-2+
  Programming Lang: C, Shell scripting, Makefile
  Description     : linux livepatching module for Debian

Livepatch modules from the Linux Kernel gives the possibility to apply
security fixes to the Kernel while minimizing the need of rebooting the
machine. We can list a lot of cases where users cannot or do not want to
reboot the system. For instance, while running complex scientific
computations, or systems that need to keeping services up and running as much
as possible without interruption. But in those cases, the system needs to be
stable and secure. Livepatching gives that possibility. For now, this package
is a prototype to do a first step to integrate linux livepatching into
Debian


More than an ITP, this is an Intent to Design an Implement.

(CCing debian-lts, since the subject was brought up there some time ago last
year, and there may be people interested. However, this is something that
should be discussed also with the kernel and the security teams. And as Ben
said during an LTS Team meeting, if this idea is implemented in Debian, it
must go through unstable first.)

Other than having serious fun, the goal of this is ITP is to bring livepatching
for security fixes for the kernel that have been available in the Debian
releases. For the moment, we are looking to design and implement a first
approach, that will live in experimental, while we solve the known and unknown
challenges.

# State of the art, what others do

As readers most be aware, some commercial distributions propose linux live
patching.  However, none of their services is freely (as in beer or as in
speech) available.

* RedHat:
Introduced Kpatch in 2014. Kpatch is packaged in debian, but its current status
is not good. It was removed from bullseye (currently only in buster, sid and
experimental)
https://www.redhat.com/en/blog/introducing-kpatch-dynamic-kernel-patching

* Suse
Released kGraft also in 2014, under GPL 2 (and 3 for userspace tools).
According to the wikipedia, it aims at being merged into the kernel, and a
minimalistic design became part of linux since 4.0.

* Ubuntu
Livepatching is included in Ubuntu Pro. No public details about the
implementation. This is offered as a service where it seems the modules are
downloaded directly from a Ubuntu server (not as a package).

# Mainline kernel

Documentation about livepatching support in the mainline kernel can be found
at:
https://www.kernel.org/doc/html/latest/livepatch/livepatch.html
We aim at building on top of it.


# Limitations and known questions

As discussed with Salvatore some time ago, there are quite some things to consider:
* Triaging issues: who and how issues would be triaged?
* Preparing patches: how patches will be selected, backported and etcetera, and
  maintained as a patch stack for specific kernel versions, during the whole life
  of a Debian release.
  We don't intend to add any extra load to the already busy Kernel or Security
  teams. We aim at maintaining this as a team though.
* Testing: what are the requirements for the testing infrastructure? What kind
  of machines are needed for testing the patches before publishing them?

Also:
* Patches should be cumulative.
  How long a specific linux version/package would be supported? The goal of
  this project is to make it possible to apply a limited set security issues
  without rebooting. Until when, for how long?
* We limit the initial prototype to non-signed images. Secure Boot does not
  allow to install non-signed modules.
* We limit the initial prototype to amd64.

The initial prototype is based on binary module packaging, contrary to what
other vendors do. We will see how this scale.

Comments and questions are welcome in the ITP bug.

Cheers,

Emmanuel and Santiago

P.S. This is the outcome of one of our conversations during the MiniDebConf in
Santa Fe, Argentina. Thanks to the people that made it possible :-)

#1070494#10
Date:
2024-06-18 15:08:31 UTC
From:
To:
Hi there,

Just to note that Emmanuel and myself may be interested in helping to
maintain kpatch. It may be useful for the linux-livepatching ITP
(https://bugs.debian.org/1070494).

Dimitri, are you still interested in maintaining kpatch? If you don't
object, we will try to package the latest version, look at the existing
bugs when it was removed, and try to reintroduce it. Any objection to
that?

Cheers,

#1070494#15
Date:
2025-02-23 16:25:47 UTC
From:
To:
Hello there,

We would like to give a short update about the linux live-patching
project, to give a couple of news that we have since the Toulouse
MiniDebConf 2024 talk.

# The future of kpatch

We have become aware of some challenges with our initial plan to rely on
kpatch, a tool that can build livepatch modules from a given patch, and
we are looking for alternatives. Our proof-of-concepts (PoCs) have
worked so far with the bookworm's 6.1 kernel. However trixie's kernel
will have CONFIG_X86_KERNEL_IBT enabled, and kpatch is unable to fully
support it.

As kpatch developers suggest [kpatch#1320], we (especially Emmanuel) are
exploring how to integrate klp-build into our plans.

[kpatch#1320] https://github.com/dynup/kpatch/issues/1320

# Communication channels

As agreed by the kernel team in the November 20th 2024 meeting, we are
happy to say that, for the moment, we may use the kernel team mailing
list for communicating progress (as these bits) and to discuss anything
related about the project. We are also available to exchange on the
#debian-kernel IRC channel @ OFTC.

Thus, if you have any questions, please don't hesitate to reach out
there.  Thanks to the kernel team!

Until the next update,

Emmanuel & Santiago