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

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

How to revoke Debian kernels for secure boot

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

Contents

  How to revoke Debian kernels for secure boot Bastian Blank <waldi@debian.org> - 2023-12-13 23:10 +0100
    Re: How to revoke Debian kernels for secure boot Dimitri John Ledkov <dimitri.ledkov@canonical.com> - 2023-12-13 23:20 +0100
      Re: How to revoke Debian kernels for secure boot Julian Andres Klode <jak@debian.org> - 2023-12-14 10:00 +0100
      Re: How to revoke Debian kernels for secure boot Steve McIntyre <steve@einval.com> - 2023-12-14 16:20 +0100
        Re: How to revoke Debian kernels for secure boot Bastian Blank <waldi@debian.org> - 2023-12-14 21:50 +0100
          Re: How to revoke Debian kernels for secure boot Bastian Blank <waldi@debian.org> - 2023-12-15 00:40 +0100

#81206 — How to revoke Debian kernels for secure boot

Hi

I don't think we currently have a documented way to revoke old kernels
for secure boot.  Are there known plans by other distributions?  Or
should we just force the inclusion of SBAT and use it as intended?

Regards,
Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
		-- Kirk, "Elaan of Troyius", stardate 4372.5

[toc] | [next] | [standalone]

#81208

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

At the moment the best options are:

- rotate online signing key
- build new shim with old signing key in vendorx (revoked ESL)
- build new kernels with old signing key built-in revoked keyring

This is to ensure that old shim & old kernel can boot or kexec new kernels.
To ensure new shim cannot boot old kernels.
To ensure that new kernels cannot kexec old kernels.

This is revocation strategy used by Canonical Kernel Team for Ubuntu
Kernels.

There is no sbat for kernels yet (and/or nobody has yet started to use sbat
for kernels).

On Wed, 13 Dec 2023, 22:04 Bastian Blank, <waldi@debian.org> wrote:

> Hi
>
> I don't think we currently have a documented way to revoke old kernels
> for secure boot.  Are there known plans by other distributions?  Or
> should we just force the inclusion of SBAT and use it as intended?
>
> Regards,
> Bastian
>
> --
> ... The prejudices people feel about each other disappear when they get
> to know each other.
>                 -- Kirk, "Elaan of Troyius", stardate 4372.5
>
>

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

#81210

On Wed, Dec 13, 2023 at 10:18:40PM +0000, Dimitri John Ledkov wrote:
> At the moment the best options are:
> 
> - rotate online signing key
> - build new shim with old signing key in vendorx (revoked ESL)
> - build new kernels with old signing key built-in revoked keyring
> 
> This is to ensure that old shim & old kernel can boot or kexec new kernels.
> To ensure new shim cannot boot old kernels.
> To ensure that new kernels cannot kexec old kernels.
> 
> This is revocation strategy used by Canonical Kernel Team for Ubuntu
> Kernels.
> 
> There is no sbat for kernels yet (and/or nobody has yet started to use sbat
> for kernels).

Reading this summary also made me realize that if we do SBAT for kernels
and want to rely it, we also need to make kernels *check* SBAT so that
it is respected at kexec.

This can be done two ways:

- You do an SBAT self-check at startup to see if you are revoked
  yourself, which is what shim does

- You check the SBAT of the kernel you are about to kexec

I'd generally prefer the self-check I think because that also applies
if you boot kernels via UEFI directly or something.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

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

#81214

Hey all,

On Wed, Dec 13, 2023 at 10:18:40PM +0000, Dimitri John Ledkov wrote:
>At the moment the best options are:
>
>- rotate online signing key
>- build new shim with old signing key in vendorx (revoked ESL)
>- build new kernels with old signing key built-in revoked keyring
>
>This is to ensure that old shim & old kernel can boot or kexec new kernels.
>To ensure new shim cannot boot old kernels.
>To ensure that new kernels cannot kexec old kernels.

Yes, this is roughly what I was thinking too. Thanks for explaining it
well here. Something else we should *also* be doing is starting public
documentation on what changes we've made to signing over time,
tracking keys, revocations etc. so that:

 * users have a chance to understand what's changed and why
 * (being honest!) *developers* have a record so we can remember too

I'm not sure the wiki is the best place for this, but I'm also not
sure this should live on the main www.d.o either. Suggestions?

>This is revocation strategy used by Canonical Kernel Team for Ubuntu Kernels.

ACK, makes sense.

>There is no sbat for kernels yet (and/or nobody has yet started to use sbat for
>kernels).

It's a difficult thing to do, especially in light of significant
pushback from upstream developers.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

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

#81215

On Thu, Dec 14, 2023 at 03:09:51PM +0000, Steve McIntyre wrote:
> On Wed, Dec 13, 2023 at 10:18:40PM +0000, Dimitri John Ledkov wrote:
> >There is no sbat for kernels yet (and/or nobody has yet started to use sbat for
> >kernels).
> It's a difficult thing to do, especially in light of significant
> pushback from upstream developers.

Well, if I read that correctly, that way mainly about policy.  We have
to define our own policy then, and then we can decide our own.  The only
problem would be that we have to carry the patch.

Bastian

-- 
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
		-- Kirk, "The Ultimate Computer", stardate 4731.3

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

#81216

On Thu, Dec 14, 2023 at 09:31:11PM +0100, Bastian Blank wrote:
> On Thu, Dec 14, 2023 at 03:09:51PM +0000, Steve McIntyre wrote:
> > It's a difficult thing to do, especially in light of significant
> > pushback from upstream developers.

Okay, I finally managed to read most of that thread.  And it boils down
to procedural problems, leading to no viable patch.

Like the submitter not wanting to take replies seriously or even sending
the patch to the correct maintainer in the first place.  To specify a
SBAT policy for upstream Linux, where people told the submitter several
times that Linux is not interested in a secure boot policy, but such a
policy needs to be defined by the signers, aka us.

So we are free to specify "linux.debian" and attach our own policy to
it.  Or "linux-debian", so we can use "linux-debian.*" for internal
things.  Or so.

Just curious: how to MOK and SBAT interact?

Regards,
Bastian

-- 
If I can have honesty, it's easier to overlook mistakes.
		-- Kirk, "Space Seed", stardate 3141.9

[toc] | [prev] | [standalone]

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

csiph-web