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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

<div dir="auto">At the moment the best options are:<div dir="auto"><br></div><div dir="auto">- rotate online signing key</div><div dir="auto">- build new shim with old signing key in vendorx (revoked ESL)</div><div dir="auto">- build new kernels with old
signing key built-in revoked keyring</div><div dir="auto"><br></div><div dir="auto">This is to ensure that old shim &amp; old kernel can boot or kexec new kernels.</div><div dir="auto">To ensure new shim cannot boot old kernels.</div><div dir="auto">To
ensure that new kernels cannot kexec old kernels.</div><div dir="auto"><br></div><div dir="auto">This is revocation strategy used by Canonical Kernel Team for Ubuntu Kernels.</div><div dir="auto"><br></div><div dir="auto">There is no sbat for kernels yet
(and/or nobody has yet started to use sbat for kernels).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Dec 2023, 22:04 Bastian Blank, &lt;<a href="mailto:waldi@debian.org">waldi@debian.org</a>&gt; wrote:<br></div><
blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>

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

Regards,<br>
Bastian<br>

-- <br>
... The prejudices people feel about each other disappear when they get<br>
to know each other.<br>
                -- Kirk, &quot;Elaan of Troyius&quot;, stardate 4372.5<br>

</blockquote></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)