Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias <eam...@debian.org>, Santiago Ruano Rincón 
<santi...@debian.org>
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@security.debian.org, 
debian-ker...@lists.debian.org, debian-...@lists.debian.org, eam...@debian.org

* Package name    : linux-livepatching   
  Version         : 0.0.1 
  Upstream Contact: Emmanuel Arias <eam...@debian.org>, Santiago Ruano Rincón 
<santi...@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 :-)

Attachment: signature.asc
Description: PGP signature

Reply via email to