I'd like to see Loren's presentation on Secure Boot The simple fact is, despite what I know you all want to hear, the majority of Linux machines out there come from discarded Windows systems. It's like people who never buy new cars but instead buy 3 or 4 year old cars - which is most people - you really want to keep an eye on what the new car people are doing (right now, it's carmakers charging subscriptions for things like heated seats and no I'm not kidding)
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. 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.) 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. Most of the fleet in my day job is like this because while most of them were manufactured prior to the new key being released, they are HP Elitedesks and Elitebooks and HP is one of the makers that Microsoft Windows Updates acts as an errand boy for, and distributes bios updates for. (Dell is another one) 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. 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. 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. 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 that happens after June I am sure lots of people will scream at MS for subverting Secure Boot but they have a long history of I don't give a damn what anyone else in the industry thinks. They are ALSO using a LOT of weasel wording on this issue. They say repeatedly that if you don't have new keys in BIOS that your PC won't be updated to close holes in the bootloader, but nowhere are they promising that they will ever include new bootloaders when they release newer windows installers, signed with the new key they are busy distributing. I'll buy the popcorn and watch the fur fly on that one. 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. Secure Boot is a good thing. It's rollout terminated widespread usage of rootkits which were extremely prevalent 2 decades ago. What I find fascinating is an increasing number of IT techs these days have NEVER SEEN a rootkit in real life, EVER. They are simply too young. But I think that there is a chance that they might make a comeback. Most residential end-user machines are run with the local user at Admin level and all it takes is a security hole, escalation, and that's that. They are now pwned and can join the Greater Iranian or China PRC mule networks to screw the rest of us over. And unfortunately it is VERY common to reinstall Windows to fix problems and to upgrade machines, so if newer Win 10 and 11 installers start showing up with updated bootloaders that do the "right thing" and are not signed by the older expired key - we may start seeing more and more machines with Secure Boot shut off. Ultimately just about all older PCs end up failing out with bad electrolytic capacitors so machines manufactured back in the 90's are all pretty much gone. And, old Intel gen 4 stuff is no longer commercially viable for resale in the used market so it's being discarded right and left also. It's also slow. But there's still a LOT of gear out there that's Intel gen 6 & 7 from the major makers, where manufacturers are busy pretending doesn't exist anymore, and the industry is pretending doesn't exist anymore, (unless they are extracting their 30 pieces of silver for to continue windows 10 updates on) so I have a feeling we will be dealing with this for many more years before it all ages out. 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
