Fuck secure boot. A fun project, even if mostly for educational purposes, would be to collect all the different exploits that have been found over the past years and try to create a universal secure boot bypass loader that targets as many of those as possible. I guess chances are that if your vendor didn't update the firmware to include the newer ms keys, they also didn't patch any of the exploits. So we just need to also get this super exploit loader signed so that it works everywhere :o)
Linux and Secure Boot certificate expiration
121–130 of 272 posts
Re: Linux and Secure Boot certificate expiration
#122Earlier quoted context omitted.
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configurat…
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.
I'll take UEFI over BIOS any time if only because it finally solved dual booting.
Re: Linux and Secure Boot certificate expiration
#123It's not just Linux - certificates to sign Windows are also affected in 2026. https://support.microsoft.com/en-us/topic/windows-secure-boo... https://techcommunity.microsoft.com/blog/windows-itpro-blog/... Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop b…
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse. In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do. In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
As a Linux user, I am shocked--shocked!--to hear that consumer hardware vendors are taking shortcuts and abandoning maintenance as soon as they can.
Re: Linux and Secure Boot certificate expiration
#124Earlier quoted context omitted.
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configurat…
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementi…
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?
This stuff seems inches away from a supply chain attack.
Re: Linux and Secure Boot certificate expiration
#125Earlier quoted context omitted.
There are things like Roblox that are really only usable under Windows due to a perverse idea of what "anti-cheat" should look like.
https://sober.vinegarhq.org/
I can confirm Sober works really well, possibly slightly smoother than the Windows client.
I couldn't get it to run via Proton/Wine at all.
Re: Linux and Secure Boot certificate expiration
#126could we just set the clock backwards on shutdown and forwards on boot? or do the keys delete themselves after the date?
Re: Linux and Secure Boot certificate expiration
#127Earlier quoted context omitted.
Call me childish, but I don’t want to ask Microsoft to sign a certificate for me before I install software onto my own hardware. I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline. Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from Secur…
> Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot. Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
Yeah that's how my systems are set up. I also appreciate that each firmware let's me restore the original keys just in case without me having to manually back them up -- but they're not active for secure boot.
Re: Linux and Secure Boot certificate expiration
#128Earlier quoted context omitted.
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signator…
Hm, I guess that's one point. 15 years worth of accumulated revoked certs is a pretty big list though, not sure how much they win there.
Idle thought - wonder if there are perfect hash-like constructions they could use for revoked certificate lists.
Re: Linux and Secure Boot certificate expiration
#129It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
If Linux users had "stepped up to the plate" and demanded their own separate PKI, nothing would be different, except that every system that shipped with Windows would be locked to Windows. Dual booting would not be a thing.
I mean, your statement is self contradictory. Linux users demanded no signing etc. So, had the industry listened to Linux users, there would be no signing. We do not live in that universe.
There are some vendors that don't have secureboot. They are e.g. System76. You can enable your own SecureBoot if you want[1], though some things may not work, like checking GPU firmware signatures, because they are signed by Microsoft only (there are other issues, depending on how deeply Microsoft is assumed in your system, see e.g "On some devices, removing either of these keys could disable all video output.")
Re: Linux and Secure Boot certificate expiration
#130Earlier quoted context omitted.
Every couple of years MS do an update that messes up multi-boot/dual boot. I'm sure it's on purpose at this point, and relatively sure "Secure Boot" is how they achieve it. Still on Windows only for kids games. Linux user since last millennium.
As a Linux-only gamer since 2019 I wonder what kids games you are talking about?
I've stopped trying to fight to install things on Linux. Anything with kernel level anticheat it seems is torment. They okay Fortnite, and quite a bit of Marvel Rivals (which initially worked, then stopped, I see reports suggesting it's working again but I don't have time to be full-time support to keep things running smoothly).
We do use Kubuntu for games that run in it without drama - Risk of Rain, Roblox (via Sober), browser games, CS2.
They also are expected to use Microsoft Office for school (UK), it's possible to work that online, but the experience is worse, slower, more prone to issues it seems.
Fwiw, I've been a Linux distro user for decades and was Linux only until the first child got to highschool. Microsoft's "educational" policy works for them!