1. Forum
  2. Usenet
  3. LINUX.DEBIAN.KERNEL

  • How to revoke Debian kernels for secure boot

    From Bastian Blank@21:1/5 to All on Wed Dec 13 23:10:02 2023
    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)
  • From Dimitri John Ledkov@21:1/5 to [email protected] on Wed Dec 13 23:20:02 2023
    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, <[email protected]> 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:[email protected]">[email protected]</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)
  • From Julian Andres Klode@21:1/5 to Dimitri John Ledkov on Thu Dec 14 10:00:02 2023
    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)
  • From Steve McIntyre@21:1/5 to Dimitri John Ledkov on Thu Dec 14 16:20:01 2023
    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. [email protected] "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)
  • From Bastian Blank@21:1/5 to Steve McIntyre on Thu Dec 14 21:50:02 2023
    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)
  • From Bastian Blank@21:1/5 to Bastian Blank on Fri Dec 15 00:40:01 2023
    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)