FYI, "this will make the build unreproducible"... :/ ----- Forwarded message from Bastian Blank <wa...@debian.org> -----
Date: Sun, 24 Sep 2023 15:01:47 +0200
From: Bastian Blank <wa...@debian.org>
To: debian-ker...@lists.debian.org
Cc: debian-b...@lists.debian.org, debian-rele...@lists.debian.org,
debian-secur...@lists.debian.org,
d...@packages.debian.org
Subject: Upcoming changes to Debian Linux kernel packages
Message-ID: <20230924130147.qwnjrq4nvkm75...@shell.thinkmo.de>
List-Id: <debian-boot.lists.debian.org>
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
information are in #1040901.
We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages. Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.
But maybe we can enhance the user experience a bit, by reducing the
chance of scarry errors, but with the chance of simple errors like "you
need to reboot". So let's do some more changes and hopefully don't
break the user experience too much. The planned changes are discussed
in more detail.
## Kernel modules will be signed with an ephemeral key
The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself. Instead a key will be created during the build
and thrown away after.
Yes, this will make the build unreproducible, but no better solution
currently exists. There are some plans, but no-one is working on them.
If a suitable replacement shows up, we can always switch to that
solution.
## Kernel release value includes complete Debian version
The kernel release is what "uname -r" shows, and how modules are
organized in /lib/modules. This value will include the complete version
of the binary package, so even binNMU will somehow work. This will make
sure the value changes with every upload and modules will not be
compatible already from that check.
Example: 6.5.3-2+b2-cloud-arm64
## Image packages contains more version info
By renaming the kernel packages we try to make several kernels
installable at the same time. In contrast to rpm, where you can have
the same package installed multiple times in different versions, dpkg
only supports a single one at the same time. So the co-installable
versions needs to have different package names.
The packages will include the full upstream version. There exists the
exception of devel builds and uploads to experimental, wich will contain
even less of the version, to avoid new names in that cases.
Example: linux-image-6.5.3-cloud-arm64
There are some drawbacks.
The same upstream version in testing and backports will have the same
package name. Multiple uploads of the same upstream version will have
the same package name, but those rarely happens. Those packages will
not be compatible and a reboot is necessary to be able to load modules
again.
It will not longer be possible to reliably derive the package name from
kernel release (see above), as both values are not really related
anymore.
## Header and tool packages will not longer contain version
The headers packages will not longer include the version. It won't be
reliably possible to derive the package name anyway from the running
kernel.
This means that only headers of one single version can be available on
the system at one time. This might be a bit inconvinient for dkms, as
it can't longer build modules for multiple versions.
But we too often have the problem that image and headers go out of sync
and then you can't find the correct ones anyway.
Example: linux-headers-cloud-arm64
## Installer packages will not longer contain too much version
The installer can only ever handle one version of kernel. Also it got
an internal mechanism to detect which packages belong together
(the Kernel-Version control entry). So we have no need to rename them
and force a matching change in d-i itself just because a new kernel
exists. So it will not longer contain the full version in the package
names if not needed.
## Further work
The changes outlined here try to avoid changes to the initramfs
protocol, aka /etc/kernel/. There are larger change is cooking somehow,
see
https://lists.debian.org/msgid-search/y2gbkyerb10ky...@shell.thinkmo.de
Regards,
Bastian
--
You! What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
----- End forwarded message -----
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
we'll all die. make a difference while you can. disobey. smile.
signature.asc
Description: PGP signature
