https://arstechnica.com/security/2023/12/just-about-every-wi...
https://arstechnica.com/security/2024/07/secure-boot-is-comp...
SecureBoot would have been better off with certificates that never expire. That's not a problem in cases where users (or organisations) manage their own hosts, since they can just changed the certificate when the previous one is no longer valid or leaked or whatever.
In practice, SecureBoot rolled out with a single CA for everyone, one controlled by Microsoft. This provides little value for anyone—restricting your computer to "only boot stuff signed by a third party" doesn't really protect from attackers in any way. They'll just boot into one of the many programs signed by MS. But because a single CA is used globally, you want expiration so as to roll them over every few years. But remember: there's no way to have a reliable clock. And so, we have the mess that we have.
The grand majority of Linux users could disable SecureBoot tomorrow and their system's security would not change in any meaningful way.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
worked perfectly on a fully updated Windows 11 24H2 installed on an old Surface Pro LTE i5-7300U that is perhaps unlikely to receive another firmware update...
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
EVERYBODY wants that! And I mean ABSOLUTELY EVERYBODY! Updates are now mandatory everywhere, in both Windows and Linux, and GPU manufactureres would LOVE to make the old cards obsolete, even if technically the new cards aren't much better.
So expect to see the old certificate invalidated quickly and automatically, in the name of security, of course!
- on a mobo the motherboard provider signs the PK
- there's only one PK
- the PK signs one or more KEK, like "Microsoft Corporation UEFI CA 2011"
If that understanding is correct, can I add myself the new "Microsoft Corporation UEFI CA 2023" (the one that expires in 2038: I think that its name) the same way I can enroll new keys in the dbx? (say my own signed keys?)If I add the new Microsoft key myself, shall it be as a KEK or in the dbx?
Will motherboard manufacturer release new firmware, with the new Microsoft key already signed? In that case, shall be a KEK ?
Basically instead of thinking, as TFA suggests: "Let's not worry about anything, everything shall be fine and keep working because keys expiration date aren't enforced", can I pro-actively enroll the new Microsoft key myself?
P.S: I don't drink the SecureBoot kool-aid but something has to be said about having a Linux unikernel (kernel+initramfs) signed and enforced by SecureBoot. And SecureBoot does at least somehow work. Source: I modified on bit of my kernel and had a SecureBoot error and the kernel refused to boot. You can try it for yourself.
So, dumb question: If the expiry dates are not enforced, why rotate the certificates at all? The only consequences of Microsoft introducing new keys seems to be that compatibility with old software and systems will over time become worse. But what's the upside - or the actual threat model this is defending against?
With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.
They could've used a time stamping service to include a signed timestamp in the binary to compare the expiry date against, but that still leaves the system unbootable after the time stamping certificate expires in the far future.
Besides, a hacking group powerful enough to steal Microsoft's Secure Boot private key will likely be able to steal a timestamping private key from a certificate authority as well.
As well as the new root certificates in db, which are used to decide whether signed code will execute or not, there will be a new signed Microsoft key for KEK. This isn't involved in the boot process, but is required for Microsoft to be able to sign further revocation updates. The article is discussing the db case, and if you want to ensure things signed only with the new key will boot on your system, you would want to add them to db.
Microsoft can sign a db update themselves (since there's a valid Microsoft key in KEK and db updates need to be signed with a key in KEK), but KEK updates need to be signed with PK. Microsoft doesn't own PK, so adding the new KEK requires the system vendor produce an update signed with their PK.
If you are in a position to enroll the new keys then you should enroll the new db keys if you want new binaries to be guaranteed to boot, and add the new KEK if you want to be able to apply future Microsoft-signed dbx updates.
Code has bugs. There's any number of critical vulnerabilities in Linux, Windows, MacOS that have allowed bypass of all security features - does that mean all security features remain security theatre?
Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks* around it and it will get italicized.*
Secure Boot is a fine thing if you're a huge corporation and want to harden laptops against untrustworthy employees, or you've got such a huge fleet of servers they go missing despite your physical security controls, or you're making a TiVo style product you want to harden against the device owners. But when the user is the device owner? Doesn't do much.
For example, you want your users' laptop hard drives to be encrypted - but also you have users who regularly forget their passwords? With bitlocker their hard drive can decrypt itself, so they only need to remember their windows login, which you can reset remotely.
You give laptops to your field workers, who have full physical access and would love to play video games or access netflix when work puts them in a hotel over night with nothing to do? With secure boot you can keep your precious spreadsheets locked down, even if they're willing to boot from USB sticks or swap the hard drive.
And perhaps most importantly, it has "secure" in the name. So the corporation's IT security auditors will like to see it turned on even if they have only a vague understanding of what it does.
The cost in terms of freedom/flexibility and reliability/longevity is very high. But we're told, this is necessary, it's the only way to guarantee the security of the poor user. But if in practice the security wasn't actually guaranteed, for most motherboards over most years, due to pretty big dumb oversights ... was it worth the extreme costs? The cost of losing compatibility with older or newer software/hardware, of losing convenient repairs and recovery? Nope.
You sold your soul for "guaranteed security" of securing the entire boot and runtime from the lowest level hardware up ... and didn't really get it anyway.
In the end what matters is always money. Always.
What brings more money? TiVo or buyer-owned device? You think 5% of technically competent potential buyers would make a difference when the 95% illiterate users will just replace the product no questions asked?
It started as a fight against piracy and half-competent users that break their own systems (and the company's systems too, like you said). But slowly the industry sees that there's more money to be made if the same technology can provide a belivable argument in right to repair and planned obsolescence court cases.
[1] https://github.com/melontini/bootloader-unlock-wall-of-shame
This sentence just makes me so sad
A decent Secure Boot implementation together with a BIOS/EFI password at least makes the life of US CBP or similar thugs wanting to use my devices against me much more difficult.
And no, that's not an imaginary threat, certainly not under this administration which has come under fire multiple times for first detaining and then deporting random tourists.
Users should absolutely be able to install the db update by hand if they choose to, but it's late and I don't have the commands to hand. I'll write another post on this soon.
Earlier versions of Windows were a much bigger threat to adoption of Windows 8 than Linux was.
Most people experience this via Windows, which automatically sets up that chain of trust so that you can know you've not had a rootkit injected somewhere. In other cases it may be Linux or something more exotic booting, and it requires some management by whoever is operating the device, but that comes with the benefit of knowing that if one of our devices has got to the point of decrypting it's storage we can be reasonably confident that it hasn't been tampered with, and so we can trust it to send good data.
Certainly. Just one problem: Modern consumer BIOS interfaces are graphical and your GPU is off.
I have never used it on my gaming PC and Windows doesn't seem to care.
The reality is that PC's address the needs of a fundamentally different market than "TiVo"s or even mobile phones. While most could, and probably should, be using secure boot noone seems to be eager to take away the option to disable it.
Throw in jail time for decision makers. Lets make markets honest with real incentives.
Its one of my interview questions these days. What device will I be issued?
If its a chromebook I know that no matter what they say they don't really care about the postion.
Anyway, it's good to hear that I probably don't have anything to worry about.
Hello from 2013, and here you go!
https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot
https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
Microsoft perennially makes small movements in that direction. Reduced control over the OS and attempts to exert control over the software ecosystem. I assume they're still trying to push consumers towards Windows S mode devices.
Kernel mode anticheat that won't run on systems that aren't attested. Streaming platforms that won't serve up decent quality streams. Even if you don't notice the pot being boiled there are those of us that do.
Do you own a phone that's easily rooted? Who else does?
What about your WiFi routers? Internet modem? AirTags? Smart home appliances?
It's still a problem if manufacturers force ExploitationOS on the device I bought, but it's not-as-bad when everyone can collaborate to disable the exploitation-parts.
Its the same theory behind the issues with the office toolbar. They find that people only use 5% of the buttons but there is almost zero overlap among millions of users.
It was even explicitly designed to prevent "tivoization." https://www.gnu.org/philosophy/tivoization.en.html
One just has to use it to prevent their software from being locked away from the end user
If you let arbitrary code run before you start checking, you don't have a secure boot chain.
Tangent: To me that sounds like a reference to the "frog boiling" story. This has been debunked [1], a healthy frog will not remain in a gradually heated pot of water. We need a better analogy for this.
On the other had I've seen execs/directors that barely turn on their PC get $10k monster laptops because they are considered important. While staff get recycled garbage equipment or a $1000 max per person equipment budget.
I'm not understanding how it's the desktop Linux users who have to deal with poor security.
Still, my point was not about running a rooted phone with unlocked bootloader (secure boot disabled on a pc equivalent), but whether if this is possible accounts in your purchasing decision.
On Linux Mint if you run a program without granting any extra permissions it can: Record your mic, record your camera, record your screen, steal your browser history/ cookies/passwords, alias sudo or show a fake update dialog to collect the user's password to elevate to root, see if you copied a crypto address and replace it with a similar looking one owned by the attacker, encrypt all of your files, send any sensitive pictures or documents to the attacker, etc.
The existence of a 50 year old concept of file permission is not good enough to combat the modern security problems users can encounter.
Lot of good that will do you when Linux users will curl | bash most any garbage.
The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting).
> thinking about whom to trust and primarily sourcing their software from the distro package manager
So "app store" is the wave of the future?
The days of Linux users using magic healing crystals to protect themselves from malware are long over. Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you.
Plus, tablets are not PCs. People are happy with tablets and phones as locked devices. They are not happy with PCs as locked devices, and have not accepted such control, maybe outside the MacOS ecosystem.
Same for Windows users who zoom through UAC prompts without reading.
> The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting).
...and much more convoluted and easy to break while most systems allow unfettered access to everywhere. On the other hand SELinux and AppArmor already provide transparent system isolation for decades now, and they are completely invisible. If you want even more security, you can install an immutable distro.
> So "app store" is the wave of the future?
App stores are capitalist versions of software repositories which are present for more than 20 years now? Plus, these repositories are generally well-vetted and observed by their maintainers.
> Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you.
No, instead many sysadmins who know what they're doing are depending on a layered security system, provided by Linux kernel and its peripheries. Containers, CGroups, namespaces, SELinux/AppArmor, package integrity checks, multiple limited users (with reduced capabilities as well), UNIX file permissions, and many more.
If you think Linux only has file permissions for system security, I have news for you.
That said, not all general purpose computing devices are useful for all things. For example: you can, but probably aren't, going to use a mobile phone for a server. On the flip side: you can use a server to do your banking, but most people won't find it as convenient as using their phone for banking (even though banking from a stationary computer is far more convenient than it was in the days when you had to go to a branch). Likewise: mobile devices can be used for content creation, but I doubt that you would find many office workers jumping at the opportunity to use them in the place of a desktop or laptop. On the other hand: someone who is on the road a lot would probably appreciate their portability.
UAC is not a security boundary, so it is not relevant when talking about security.
>SELinux and AppArmor already provide transparent system isolation for decades
If they are setup and most Linux distros only limit individual apps. So a brand new app can still run wild.
>you can install an immutable distro.
Even immutable distros let people download new software off the internet and run it.
>Plus, these repositories are generally well-vetted and observed by their maintainers.
This has been shown to be false in practice due to the xz backdoor. Maintainers do not actually vet anything other than that the code is coming from the developer. Which is also what app stores do.
That is there excuses but you don't seem to realize that this makes it only worse because that means there is no boundary at all.
>If they are setup and most Linux distros only limit individual apps. So a brand new app can still run wild.
new apps will be either installed from a trusted repository (often with a MAC profile) or sandboxed by default from flatpak/snap store. You don't seem to understand that the entire install process is different. You don't get your software from random sites found on Google between malware ads on Linux.
>This has been shown to be false in practice due to the xz backdoor
XZ has nothing to to with a lack of vetting and even if it was it would be an argument for it because it got caught in testing.
Full disk encryption on a device you have full control of is sufficient.
Containerization helps if you install untrusted apps.
Not having root helps if you install untrusted apps (either vulnerabilities/exploitable or malicious) as root.
This is absolutely false, it was not caught in any sort of regular testing whatsoever.
It was caught by - of all people - a Microsoft employee who noticed SSH logins were taking a split second too long. Not distro packagers. The packages were already staged in the testing branches of the distros they were targeting and could have easily made it into the LTS versions had this one curious MS guy not noticed.
Don't trust containers to have the same level of isolation as a VM.
LTS doesn't mean set in stone. Debian publishes fixes within 24 hours in most cases, even if the upstream doesn't provide any, plus some packages come with Debian's own security patches on top of upstream patches.
Linux security landscape is very different than Windows' central "we'll patch it when we patch it" stance.
>The packages were already staged in the testing branches
Thanks for making my argument for me. It was also literally caught in (Debian) TESTING.
It does not matter for who he works unless you believe a cooperation owns there employees time and achievements 24/7.
He notices something off, tested it, looked at the source code (impossible on windows ;) and reported the issue he found which got quickly and transparently (also impossible on windows) fixed. Again that is how FOSS should work and why it's superior to proprietary software.
LWN wrote an article which opens with the assertion "Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September". This is, depending on interpretation, either misleading or just plain wrong, but also there's not a good source of truth here, so.
First, how does secure boot signing work? Every system that supports UEFI secure boot ships with a set of trusted certificates in a database called "db". Any binary signed with a chain of certificates that chains to a root in db is trusted, unless either the binary (via hash) or an intermediate certificate is added to "dbx", a separate database of things whose trust has been revoked[1]. But, in general, the firmware doesn't care about the intermediate or the number of intermediates or whatever - as long as there's a valid chain back to a certificate that's in db, it's going to be happy.
That's the conceptual version. What about the real world one? Most x86 systems that implement UEFI secure boot have at least two root certificates in db - one called "Microsoft Windows Production PCA 2011", and one called "Microsoft Corporation UEFI CA 2011". The former is the root of a chain used to sign the Windows bootloader, and the latter is the root used to sign, well, everything else.
What is "everything else"? For people in the Linux ecosystem, the most obvious thing is the Shim bootloader that's used to bridge between the Microsoft root of trust and a given Linux distribution's root of trust[2]. But that's not the only third party code executed in the UEFI environment. Graphics cards, network cards, RAID and iSCSI cards and so on all tend to have their own unique initialisation process, and need board-specific drivers. Even if you added support for everything on the market to your system firmware, a system built last year wouldn't know how to drive a graphics card released this year. Cards need to provide their own drivers, and these drivers are stored in flash on the card so they can be updated. But since UEFI doesn't have any sandboxing environment, those drivers could do pretty much anything they wanted to. Someone could compromise the UEFI secure boot chain by just plugging in a card with a malicious driver on it, and have that hotpatch the bootloader and introduce a backdoor into your kernel.
This is avoided by enforcing secure boot for these drivers as well. Every plug-in card that carries its own driver has it signed by Microsoft, and up until now that's been a certificate chain going back to the same "Microsoft Corporation UEFI CA 2011" certificate used in signing Shim. This is important for reasons we'll get to.
The "Microsoft Windows Production PCA 2011" certificate expires in October 2026, and the "Microsoft Corporation UEFI CA 2011" one in June 2026. These dates are not that far in the future! Most of you have probably at some point tried to visit a website and got an error message telling you that the site's certificate had expired and that it's no longer trusted, and so it's natural to assume that the outcome of time's arrow marching past those expiry dates would be that systems will stop booting. Thankfully, that's not what's going to happen.
First up: if you grab a copy of the Shim currently shipped in Fedora and extract the certificates from it, you'll learn it's not directly signed with the "Microsoft Corporation UEFI CA 2011" certificate. Instead, it's signed with a "Microsoft Windows UEFI Driver Publisher" certificate that chains to the "Microsoft Corporation UEFI CA 2011" certificate. That's not unusual, intermediates are commonly used and rotated. But if we look more closely at that certificate, we learn that it was issued in 2023 and expired in 2024. Older versions of Shim were signed with older intermediates. A very large number of Linux systems are already booting certificates that have expired, and yet things keep working. Why?
Let's talk about time. In the ways we care about in this discussion, time is a social construct rather than a meaningful reality. There's no way for a computer to observe the state of the universe and know what time it is - it needs to be told. It has no idea whether that time is accurate or an elaborate fiction, and so it can't with any degree of certainty declare that a certificate is valid from an external frame of reference. The failure modes of getting this wrong are also extremely bad! If a system has a GPU that relies on an option ROM, and if you stop trusting the option ROM because either its certificate has genuinely expired or because your clock is wrong, you can't display any graphical output[3] and the user can't fix the clock and, well, crap.
The upshot is that nobody actually enforces these expiry dates - here's the reference code that disables it. In a year's time we'll have gone past the expiration date for "Microsoft Windows UEFI Driver Publisher" and everything will still be working, and a few months later "Microsoft Windows Production PCA 2011" will also expire and systems will keep booting Windows despite being signed with a now-expired certificate. This isn't a Y2K scenario where everything keeps working because people have done a huge amount of work - it's a situation where everything keeps working even if nobody does any work.
So, uh, what's the story here? Why is there any engineering effort going on at all? What's all this talk of new certificates? Why are there sensationalist pieces about how Linux is going to stop working on old computers or new computers or maybe all computers?
Microsoft will shortly start signing things with a new certificate that chains to a new root, and most systems don't trust that new root. System vendors are supplying updates[4] to their systems to add the new root to the set of trusted keys, and Microsoft has supplied a fallback that can be applied to all systems even without vendor support[5]. If something is signed purely with the new certificate then it won't boot on something that only trusts the old certificate (which shouldn't be a realistic scenario due to the above), but if something is signed purely with the old certificate then it won't boot on something that only trusts the new certificate.
How meaningful a risk is this? We don't have an explicit statement from Microsoft as yet as to what's going to happen here, but we expect that there'll be at least a period of time where Microsoft signs binaries with both the old and the new certificate, and in that case those objects should work just fine on both old and new computers. The problem arises if Microsoft stops signing things with the old certificate, at which point new releases will stop booting on systems that don't trust the new key (which, again, shouldn't happen). But even if that does turn out to be a problem, nothing is going to force Linux distributions to stop using existing Shims signed with the old certificate, and having a Shim signed with an old certificate does nothing to stop distributions signing new versions of grub and kernels. In an ideal world we have no reason to ever update Shim[6] and so we just keep on shipping one signed with two certs.
If there's a point in the future where Microsoft only signs with the new key, and if we were to somehow end up in a world where systems only trust the old key and not the new key[7], then those systems wouldn't boot with new graphics cards, wouldn't be able to run new versions of Windows, wouldn't be able to run any Linux distros that ship with a Shim signed only with the new certificate. That would be bad, but we have a mechanism to avoid it. On the other hand, systems that only trust the new certificate and not the old one would refuse to boot older Linux, wouldn't support old graphics cards, and also wouldn't boot old versions of Windows. Nobody wants that, and for the foreseeable future we're going to see new systems continue trusting the old certificate and old systems have updates that add the new certificate, and everything will just continue working exactly as it does now.
Conclusion: Outside some corner cases, the worst case is you might need to boot an old Linux to update your trusted keys to be able to install a new Linux, and no computer currently running Linux will break in any way whatsoever.
[1] (there's also a separate revocation mechanism called SBAT which I wrote about here, but it's not relevant in this scenario)
[2] Microsoft won't sign GPLed code for reasons I think are unreasonable, so having them sign grub was a non-starter, but also the point of Shim was to allow distributions to have something that doesn't change often and be able to sign their own bootloaders and kernels and so on without having to have Microsoft involved, which means grub and the kernel can be updated without having to ask Microsoft to sign anything and updates can be pushed without any additional delays
[3] It's been a long time since graphics cards booted directly into a state that provided any well-defined programming interface. Even back in 90s, cards didn't present VGA-compatible registers until card-specific code had been executed (hence DEC Alphas having an x86 emulator in their firmware to run the driver on the card). No driver? No video output.
[4] There's a UEFI-defined mechanism for updating the keys that doesn't require a full firmware update, and it'll work on all devices that use the same keys rather than being per-device
[5] Using the generic update without a vendor-specific update means it wouldn't be possible to issue further updates for the next key rollover, or any additional revocation updates, but I'm hoping to be retired by then and I hope all these computers will also be retired by then
[6] I said this in 2012 and it turned out to be wrong then so it's probably wrong now sorry, but at least SBAT means we can revoke vulnerable grubs without having to revoke Shim
[7] Which shouldn't happen! There's an update to add the new key that should work on all PCs, but there's always the chance of firmware bugs