Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank <waldi@debian.org>]

Hi Andreas

On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## 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.
> 
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?

Yes.  Nothing calls for changes to MOK keys, which are used by dkms.

> > ## Header and tool packages will not longer contain version
> 
> > 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.
> 
> That sounds problematic in case of third party modules. If it is possible to
> have multiple linux-image-* packages installed, but only headers for one of
> them, the third-party modules will only be available for one of the kernel
> versions for sure (maybe there are still old module builds available, but no
> guarantee especially after the third-party module got updated). This will
> make switching between different kernel versions difficult to impossible,
> e.g. it may be hard to go back to a working older kernel version in case the
> new one does not work properly (or the third-party module cannot be built or
> does not work for the new version).

Already built modules remain until someone deletes it.  So you can also
switch back to the still installed older kernel version and it will have
the still working module available.

Yes, you would not be able to build new modules for the older kernel
until you also install the matching headers.

> Regarding getting the correct linux-header-* packages installed for the
> installed linux-image-* packages:
> Maybe linux-image-* could have
>   Recommends: linux-headers-* | no-linux-headers
> s.t. the correct linux-headers-* are installed by default (installation of
> recommends is enabled by default) for all installed linux-image-* packages.
> no-linux-headers would be an opt-out package that can be installed manually
> if someone does not want to get linux-headers-* installed at all. It should
> never be installed automatically.

Nack.  I actually thought about that.  But third-party modules are too
much a special configuration to do that and pay the 50MiB or so penalty
for each system.  Also this still have the version skew problem between
linux and linux-signed-*, so will be unreliable.

> For dkms it is hard recommend the correct linux-header-* package, right now
> we have
>   Recommends: linux-headers-generic | linux-headers-686-pae |
> linux-headers-amd64 | linux-headers
> which does not really work for the non-default kernel flavor, e.g. the
> -cloud or -i386 kernel. So some improvement on the kernel side would be nice
> here.

I thought about adding a versioned provides with the complete kernel
release string as version, so something like
| Provides: linux-headers (= $(uname -r))

This can then be installed via apt-get and the correct version as long
as the package is available.  This however can't be done via
dependencies, because it is dynamic.  So dkms would need to actively
make sure it got the correct package, if they are still reachable at
all.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
		-- Kirk, "The Gamesters of Triskelion", stardate 3211.7