On Wed, Apr 22, 2026 at 07:28:17AM -0700, Ted Mittelstaedt wrote: > I'd like to see Loren's presentation on Secure Boot
I haven't had a chance to catch up on the full thread, but here's some pre-meeting warm-ups. > > The TLDR is after June, any machine that does not have the new keys in it's > BIOS will NOT Secure Boot a Linux (or Windows) install stick with an updated > bootloader. This has been a big discussion at work as well primarily within the Linux users group that need to stay compliant with IT policy. > > BUT BUT BUT - there's "what ifs" to this. > > The first one is that it SEEMS that there's actually 2 separate places in a > UEFI boot where this matters. I don't understand exactly how Secure Boot > works - Loren probably knows more - and it's not particularly easy to find > good technical information on it - but what appears to be happening is you > have the BIOS which uses the key to load UEFI and then UEFI uses the key to > load the OS bootloader (windows, Linux, etc.) Yes, it's ultimately a chain of trust. And with typical Linux boot loaders, there are a few more steps as I'll talk about. shim is trusted by Microsoft, but then has an embedded key to trust GRUB and distro-provided kernels/modules. Then another key can be added called the MOK for user-installed third-party kernels/modules. There is a reason for it, but it's a lot to deal with for and end-user that just wants their Nvidia drivers to work. > > If you have a BIOS that was released after the new key was released 3 years > ago - and it's a PC that's been manufactured after that date or it's an > older PC that was firmware updated BIOS with a firmware update with the new > keys - then you are gold. Regardless of what Windows Updates may do to the > machine, there won't be a problem wiping it and installing Linux OR Windows > on it. If the disk is blanked out - either of those installs will recreate > UEFI with the new key, and Secure Boot will be preserved. Generally, the install doesn't add new root keys, although firmware/BIOS updates can update the keys in the UEFI firmware variables. These are generally signed by the PK that the BIOS vendor embeds in the firmware to begin with. Also, most BIOS implementations for x86 PC markets can be put into a Setup Mode that allows a user to replace all the keys arbitrarily. I'll hopefully be demonstrating this during the presentation. > Even if the BIOS is old and grotty and it's owner has blocked bios updates, > as long as a firmware update is available, at the worst you can do the > hideous hack of backdating the clock, loading some antique Windows 10 from > an old bootstick on it, keeping it off the network using the Shift+F10 hack, > and once you get it running windows, copy over the new BIOS update file, run > it, update the BIOS, then shut it down and reset everything and start over > again with the latest installer on a boot stick. Either turning off Secure Boot or installing custom keys in the Setup Mode should avoid the need for backdating the clock. The latter just is a little more complicated for an end-user who hasn't spent much time playing with X.509 certificate management and Secure Boot. > > In the Windows World, there's a lot of focus on Windows Updates fixing > everything on old PCs. Most of that boils down to updating the keys in the > UEFI partition on the disk. If for example you have an Intel-based Lenovo > generation 6 CPU that Lenovo has no new BIOS update for, you can set up a > machine with an old UEFI partition that will boot using the old keys but has > the new key in it which will boot windows or Linux or whatever you want. > But, this is for machines that have an intact UEFI partition. And - it > basically defeats the purpose of Secure Boot because effectively you are > booting off a machine with an expired key in it. So what's the point of > even using public keys in the first place? But that's an academic > discussion I suppose. What it comes down to is you still have a machine > where it's not got new keys in BIOS and so reinstallation of any operating > system after June is where the fun is. Secure Boot certificated and revocation lists are all kept in a special storage for UEFI firmware variables and are not on the EFI System Partition, at least not the Root of Trust. There can be additional certificates that are trusted because there is a valid, not expired chain of signatures back to a trusted root certificate in the PK, KEK, or db UEFI firmware variables. These variables are read-only unless in a specific Secure Boot state that must be during preboot and, if Secure Boot is enforced, can only be modified by a signed request. > > My testing seems to indicate that the Windows installers for Win10 and Win > 11 -do not- install new keys into the TPM chip (even though in theory it's > possible) for machines that lack updated BIOS firmware with the new keys. > In theory this means you can't reinstall Windows on any of these machines > after June. But even if you could - lose CMOS battery and any stored keys > in BIOS or TPM chip disappear or reset BIOS and they disappear so you are > right back to where you were. The TPM chip is a whole other presentation in and of itself, maybe one I'll work on for my next appearance, but the keys it holds are not part of Secure Boot. It does include something called a PCR and PCR 7 is used to measure Secure Boot state, but only at request of the UEFI firmware. It can be used to do things like auto-unlock an encrypted Bitlocker or LUKS disk, but only if certain conditions hold such as the current Secure Boot state. In other words, a BIOS update that updates the Secure Boot variables in any way can cause PCR 7 to hold a different hash value and cause Windows or Linux to request a passphrase (Bitlocker recovery key for Windows users) to unlock the disk and the TPM will need to be re-enrolled to update the auto-unlock support. Also, the TPM will normally use non-volatile Flash memory for it's root seed and not rely on the CMOS battery to keep it safe. > > But the hole in all of this is that since Microsoft holds the keys - could > they not in theory in their secret little room where they hold the master > key from 2011 - when their devs release the next build of Windows 10 (for > the paying customers paying for updates on 10) and windows 11 - could they > simply not just change the clock on the signing machine and sign the new > bootloader with the old key? > > Then even the latest builds of Win 11 and Win 10 with the latest installers > would boot off older machines that lack the new keys in BIOS. And then the > windows installer will of course rewrite UEFI and you end up then with old > BIOS key - and both old and new keys in UEFI. And as long as you then don't > delete UEFI during a Linux install - you are gold. Am I right, am I right? If the Windows installer could just modify the UEFI with different signing keys, that would invalidate part of the promise of Secure Boot. Granted, as Microsoft owns both, there are no guarantees. However, generally, updates to the Secure Boot Root of Trust come the platform developer who installed the original PK. https://uefi.org/specs/UEFI/2.11/32_Secure_Boot_and_Driver_Signing.html#enrolling-key-exchange-keys https://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/KE://github.com/microsoft/secureboot_objects/tree/main/PostSignedObjects/KEK > > Secure Boot to me on Linux has always been a bit of a mystery - how do the > maintainers of distros go about getting their bootloaders signed. That's > another one that Loren probably knows more about. But what I think it's > going to boil down to is a LOT of second generation retired Windows machines > that get Linux reloaded on them OR get Windows 11 reloaded on them using the > Rufus Hack, are just going to have Secure Boot shut off on them. And this > may turn into be a much bigger problem later. Bigger distros like Fedora and Debian pay Microsoft money to get their bootloaders signed by an official Certificate Authority embedded in most UEFI firmwares. Other distros might provide guides on how to use an officially signed bootloader or might not even care and just tell you to turn off that feature. > > Ted > > -----Original Message----- > From: PLUG <[email protected]> On Behalf Of Ted Mittelstaedt > Sent: Monday, April 20, 2026 8:36 PM > To: 'Portland Linux/Unix Group' <[email protected]>; [email protected] > Cc: [email protected] > Subject: Re: [PLUG] [PLUG-ANNOUNCE] Speaker for May General Meeting? > > Have you run into any systems that are in violation of the Secure Boot > requirements that mandate that Secure Boot can be disabled? > > (I'm not addressing the issues with an already installed system that was > installed Secure Boot) > > I've only had to deal with the Nvidia signed driver thing once so far. As I > recall it was one of those answer a string of questions right things, and if > you mess up one of them the house of cards collapses and you have to start > the OS install all over again. > > I particularly like the systems where when you disable Secure Boot in BIOS, > the operating system install sees it then installs the OS secure boot anyway > - so you then are forced to re-enable it in BIOS to get the system to boot. > Much common sense when into THAT one, :-/ > > Ted > > -----Original Message----- > From: PLUG <[email protected]> On Behalf Of Loren M. Lang > Sent: Monday, April 20, 2026 7:25 PM > To: [email protected] > Cc: [email protected]; PLUG <[email protected]> > Subject: Re: [PLUG] [PLUG-ANNOUNCE] Speaker for May General Meeting? > > On Mon, Apr 20, 2026 at 07:08:39PM -0700, Russell Senior wrote: > > Hi, > > > > So it looks like Jesse, our planned speaker for last month is not > > going to be available for May either, so I am short one speaker. > > Someone, whose name I don't remember or perhaps never caught, talked > > to me at prior PLUG meetings about being willing to talk and had at > > least > one subject in mind. > > If this sounds like you, PLEASE GET IN TOUCH at your earliest > > convenience, because it looks like we need you for May 7th. > > I believe that was me. The topic I was proposing was Secure Boot and how to > deal with the upcoming certificate updates that are going to be required > when the old Microsoft CA expires in June. Many systems will need this > update. > > I am hoping to go into the details of both installing your own certificates > if you don't want to use the Microsoft certificates and how to deal with the > Microsoft CA when you need to such as fulling the IT requirements for your > employeer when you want to run Linux as your main operating system. I've had > to deal with that to get my primary work laptop dual-boot enabled and with > working Nvidia drivers that needed to be signed with a MOK. > > I will mark down May 7th on my calendar for that. > > Cheers, > Loren > K7IW > > > > > > > -- > > Russell Senior > > PLUG Volunteer > > [email protected] > > _______________________________________________ > > PLUG: https://pdxlinux.org > > PLUG-announce mailing list > > [email protected] > > https://lists.pdxlinux.org/mailman/listinfo/plug-announce > > -- > Loren M. Lang > [email protected] > http://www.north-winds.org/ > IRC: penguin359 > > > Public Key: http://www.north-winds.org/lorenl_pubkey.asc > Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA > > -- Loren M. Lang [email protected] http://www.north-winds.org/ IRC: penguin359 Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA
signature.asc
Description: PGP signature
