Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 09:31:11PM +0100, Bastian Blank wrote: > On Thu, Dec 14, 2023 at 03:09:51PM +, 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
Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 03:09:51PM +, Steve McIntyre wrote: > On Wed, Dec 13, 2023 at 10:18:40PM +, 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
Re: How to revoke Debian kernels for secure boot
Hey all, On Wed, Dec 13, 2023 at 10:18:40PM +, 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.st...@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
Re: How to revoke Debian kernels for secure boot
On Wed, Dec 13, 2023 at 10:18:40PM +, 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
Re: How to revoke Debian kernels for secure boot
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, 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 > >
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
