Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #79575 > unrolled thread

Debian Kernel version and ABI in respect of #1040901

Back to article view | Back to linux.debian.kernel

Contents

  Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-07-13 21:40 +0200
    Re: Debian Kernel version and ABI in respect of #1040901 Adrian Bunk <bunk@debian.org> - 2023-07-13 22:50 +0200
      Re: Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-07-17 12:10 +0200
    Re: Debian Kernel version and ABI in respect of #1040901 Ben Hutchings <ben@decadent.org.uk> - 2023-07-14 16:20 +0200
      Re: Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-07-17 12:10 +0200
    Re: Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-07-23 10:10 +0200
      Re: Debian Kernel version and ABI in respect of #1040901 Adrian Bunk <bunk@debian.org> - 2023-07-24 22:00 +0200
        Re: Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-09-03 11:40 +0200
      Re: Debian Kernel version and ABI in respect of #1040901 Bastian Blank <waldi@debian.org> - 2023-09-03 11:40 +0200

#79575 — Debian Kernel version and ABI in respect of #1040901

Hi folks

You might have heard that the masters of Linux Secure Boot, aka shim
reviewers, have spoken.  They have told us that our way of handling
kernel modules is not longer acceptable.  For some context see #1040901.

This means for us that we have to make sure that kernel and modules
can't be mixed between different builds.  If we want to continue with
the current behaviour, where you can keep old kernels usable, we have to
rename packages and kernel internal ABI on every upload.

This is the first version of a proposal that should work. But it also
ignores some Debian and release policy points to avoid some problematic
behaviour.  For example it should not possible for package names to grow
unrestricted.

Please share your thoughts or if we have a better solution overall.

Regards,
Bastian

## Current behaviour

Currently in use are the following types:

* experimental:
    Version 6.1~rc2-3~exp4, 6.1.2-3~exp4
    ABI 6.1.0-0-arm64
* unstable/testing/stable:
    Version 6.1.2-3
    ABI 6.1.0-1-arm64
* security/LTS:
    Version 6.1.2-3~deb12u4
    ABI 6.1.0-1-arm64
* backports:
    Version 6.1.2-3~bpo12+4
    ABI 6.1.0-0.bpo.1-arm64

But our version check allows allow more variants, including NMU, BinNMU,
local versions, +bpo, ~deb11u1~deb10u1.

## Proposed behaviour

This tries to make sure everything apart from experimental gets new
names and ABI on every upload.

* experimental:
    Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
    Keep ABI 6.1.0-0-arm64
* unstable/testing/stable:
    Keep version 6.1.2-3
    ABI 6.1.2-3-arm64
* security:
    Use same version ranges as stable, makes it impossible to do stable
    and security with the same minor.
    Version 6.1.2-3
    ABI 6.1.2-3-arm64
* backports:
    Keep version 6.1.2-3~bpo12+4
    ABI 6.1.2-3.bpo12.4-arm64
* LTS:
    Version 6.1.2-3~deb12u4
    ABI 6.1.2-3.deb12.4-arm64
* Everything else:
    Not for Debian archive.
    Keep version
    ABI 6.1.2-local

## Removed feature for now

### NMU

Can be easily added back by adding "bX" or so to the ABI.

### BinNMU

Is impossible to support.  The version change requires changes in the
names of the created packages.

### Release team prefix

The release team mandated debXuY suffix is not used for any
stable/security or similar release.  Only the LTS one for now uses that.

This makes sure we never accrue more then one such suffix in any
version, to make sure it does not grow unlimited.

New stable uploads always try to gather new upstream minor releases, so
we should be safe.

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
		-- Spock, "This Side of Paradise", stardate 3417.3

[toc] | [next] | [standalone]

#79578

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
>...
> ### NMU
> 
> Can be easily added back by adding "bX" or so to the ABI.

That would be confusing, bX is naming convention for binNMUs in Debian 
revisions.

> ### BinNMU
> 
> Is impossible to support.  The version change requires changes in the
> names of the created packages.
>...

It should only be impossible to make them co-installable,
or what other reason requires a rename?

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#79630

Hi

On Thu, Jul 13, 2023 at 11:28:31PM +0300, Adrian Bunk wrote:
> On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
> > ### NMU
> > Can be easily added back by adding "bX" or so to the ABI.
> That would be confusing, bX is naming convention for binNMUs in Debian 
> revisions.

Right.

> > ### BinNMU
> > 
> > Is impossible to support.  The version change requires changes in the
> > names of the created packages.
> >...
> It should only be impossible to make them co-installable,
> or what other reason requires a rename?

The contents are incompatible.  We can of course completely remove the
ability to load modules after a kernel upgrade and then install
everything into "linux-image-amd64".

Bastian

-- 
Deflector shields just came on, Captain.

[toc] | [prev] | [next] | [standalone]

#79595

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote:
[...]
> ## Proposed behaviour
> 
> This tries to make sure everything apart from experimental gets new
> names and ABI on every upload.
> 
> * experimental:
>     Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
>     Keep ABI 6.1.0-0-arm64
[...]

Why would that still be acceptable in experimental?

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.

[toc] | [prev] | [next] | [standalone]

#79631

On Fri, Jul 14, 2023 at 04:17:34PM +0200, Ben Hutchings wrote:
> On Thu, 2023-07-13 at 21:16 +0200, Bastian Blank wrote:
> [...]
> > ## Proposed behaviour
> > 
> > This tries to make sure everything apart from experimental gets new
> > names and ABI on every upload.
> > 
> > * experimental:
> >     Keep version 6.1~rc2-3~exp4, 6.1.2-3~exp4
> >     Keep ABI 6.1.0-0-arm64
> Why would that still be acceptable in experimental?

What do you mean?  We don't check for any ABI incompatibilities forever
in experimental builds.  And the signature check will refuse to load
modules not from the same build if lockdown is enabled.

So the ABI as listed in the image and the package just means it is
provided in the same package and can be upgraded directly.

We can also decide that we don't want to make it that explicit and do:

ABI/package name only includes upstream version (6.1.1) and multiple
Debian revisions of that will be incompable to each other on lockdown
systems, but may work (depending on symvers) on non-lockdown systems.

It does not happen often that we do multiple Debian revisions of most
upstream version anyway, so people will only feel that if they upgrade
directly from backports to a different release of the same version.

Bastian

-- 
Fascinating, a totally parochial attitude.
		-- Spock, "Metamorphosis", stardate 3219.8

[toc] | [prev] | [next] | [standalone]

#79699

On Thu, Jul 13, 2023 at 09:16:15PM +0200, Bastian Blank wrote:
> Please share your thoughts or if we have a better solution overall.

After a lot of thinking, maybe a solution that allows for incompatible
package updates without renames would be more useful.  Something like:

We uncouple the package names and ABI.  The ABI will include the
complete version, so every rebuild will change it.  The package names
can include just the upstream version, aka 6.1.1.

This means:
- Every module will be compatible always only with the exact version.
- External modules needs rebuilds for every update of a image package.

We already say: You need to reboot after kernel upgrade, because the ABI
only provides compatibility from older modules to newer kernels.  This
would be now enforced by complete lack of compatibility.

In the end this is what the RedHat world does AFAIK.  They can install
multiple versions of the same package at the same time, so you have just
"kernel" installed in multiple versions.

Regards,
Bastian

-- 
Murder is contrary to the laws of man and God.
		-- M-5 Computer, "The Ultimate Computer", stardate 4731.3

[toc] | [prev] | [next] | [standalone]

#79748

On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
>...
> We uncouple the package names and ABI.  The ABI will include the
> complete version, so every rebuild will change it.

That's also what I meant with "It should only be impossible to make them 
co-installable".

> The package names
> can include just the upstream version, aka 6.1.1.

I am not convinced about that part in all cases.

> This means:
> - Every module will be compatible always only with the exact version.
> - External modules needs rebuilds for every update of a image package.
> 
> We already say: You need to reboot after kernel upgrade, because the ABI
> only provides compatibility from older modules to newer kernels.  This
> would be now enforced by complete lack of compatibility.
>...

It is under our control when to not rename the packages,
to prevent this issue for production systems.

A binNMU for a perl transition might reach testing users,
but these should not be production systems.

When it takes 3 attempts in *stable-pu to get the kernel to build on all 
release architectures, only the last one will ever reach *stable.

A policy question is that it might be a good idea to rename the packages 
when publishing a regression update for a DSA, that's the only place I see
where this problem might otherwise reach production systems.

> Regards,
> Bastian

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#80284

On Mon, Jul 24, 2023 at 10:36:47PM +0300, Adrian Bunk wrote:
> A policy question is that it might be a good idea to rename the packages 
> when publishing a regression update for a DSA, that's the only place I see
> where this problem might otherwise reach production systems.

Adding another modifier later is easy, as long as the overall setup
works.

Bastian

-- 
Oblivion together does not frighten me, beloved.
		-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
		   stardate 4770.3.

[toc] | [prev] | [next] | [standalone]

#80283

On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
> After a lot of thinking, maybe a solution that allows for incompatible
> package updates without renames would be more useful.  Something like:
> 
> We uncouple the package names and ABI.  The ABI will include the
> complete version, so every rebuild will change it.  The package names
> can include just the upstream version, aka 6.1.1.

And in addition: header and other support packages are not longer
renamed.  So they can only be installed once and need to be searched by
the actual version of the image package.

In any way, everything is weird and broken.  We currently often run
into uninstallable meta packages, due to the signing stuff adding a race
condition between the availability of the header packages and the image
packages.  Then people tend to not reboot, so they are searching for
older headers, which are already removed.  And there is no really good
solution.

The only real solution would be to always bundle headers and images and
install everything.  But this will make everything 50MB larger and does
not fit for things like the stripped down cloud kernels.

Regards,
Bastian

-- 
What kind of love is that?  Not to be loved; never to have shown love.
		-- Commissioner Nancy Hedford, "Metamorphosis",
		   stardate 3219.8

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web