They left out the steps to update it. I made a rough attempt at a document for this. [1] Please let me know if I missed a validation step. I have done this on six machines but they were all Linux. Not tested on BSD.
Archive [2] in the event I was too aggressive in blocking bots.
[Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.
FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
I actually did that on purpose since all browsers support brotli I risked the possibility someone might have disabled it with an add-on. I wanted to see how many bots that would break. It may not be the most logical process but I just use CanIUse [1] to see what supports Brotli. I ignore the Opera Mini block as they seem to support almost nothing.
Nothing wrong with that. I think people should be able to disable anything they want. I doubt any commercial sites will do what I am doing. I use that little blog to test all manor of unorthodox things. That's why I listed the archive mirror, just in case.
I've seen commercial sites hard-code gzip content in all their responses regardless of the Accept headings. Probably just as fair to use Brotli these days.
Similarly, I've been using zopfli (gzip/unzip compatible) for png compression after quantization for db storage from 2-color (B/W) scans as it's directly compatible to the browser but winds up about 1/6 the original sized tiff. Not the best compression, had a discussion for a better compression, but required a wasm renderer to decompress as it isn't in the browser box.
I had to vouch your comment, not sure what happened there. Something in your technical output must have triggered HN. One can use mokutil to see if Secure Boot is enabled after installing it. I assume the OEM installation or update of the BIOS must have included that cert but I am just guessing.
My ASUS laptop had it enabled. I had to disable it as there just wasn't enough non volital memory to hold all the updates even after remove several EFI entries and resetting the BIOS. All my mini-PC's updated fine however. My Linux Protectli routers already had it disabled thankfully. They use Coreboot, unsure if that was a factor.
To check my secure boot keys. As long as there's 2023 Microsoft keys you should be fine. Otherwise, my understanding is that you just need to update your firmware, but please somebody correct me if I'm wrong.
Do note that being able to completely remove MS keys is highly dependent on your mainboard. Not in the sense of if they allow you to do it (I think most if not all DIY boards allow you to), but if you will be able to boot afterwards.
I (soft?)bricked a mainboard and it doesn't want to boot anymore after I removed the MS keys. The worst part is, that it has a dualBIOS and no active switch to change between them, only their own "I'll change when I see issues"... well you can guess how well that worked out (and I am not able to get it to clear CMOS for some reason).
I've honestly always kept secure boot off on my machines (which also use Arch). I don't really feel like the level of threat from someone (or me, by accident) booting an image I don't want them to on my hardware is particularly worth the hassle it brings; nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
> nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
The threat model secure boot was actually designed to protect against is not someone else booting a different OS in your hardware; the real threat model it protects against is malware loading before the OS can start the antivirus. With UEFI, malware could in theory run even when you boot from your OS install media, making it much harder to detect and remove. That's the reason installing your own secure boot key requires a one-time confirmation through a physical input device (which malware can't fake).
Unfortunately, protecting against that threat model (persistent malware loading before the OS) created another threat model, which IMO is a bigger worry: that you could one day be forbidden from running your own OS in your own devices. AFAIK, there have already been a few devices where secure boot cannot be disabled, your own secure boot keys cannot be enrolled, and the "third party" (aka "non-Microsoft") key is not available.
I'm inclined to agree when it comes to desktops or servers. However I feel like a laptop needs better security, including secure boot and full disk encryption, since you could lose it and cannot be sure what it went through even if you get it back somehow.
I do use FDE on my laptop, but not secure boot. I guess I'm not particularly concerned about whether someone will load a kernel onto my boot partition and then return the laptop to me. I could always just clear out my boot partition and then set it up manually again from an Arch USB, and that would still be far less hassle than turning in secure boot.
I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs.
Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware).
Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.
No, distros uses a shim binary that is less likely to need updates. If that shim needs an update (only signed with the new key) then we get into a situation where old machines will fail to boot it.
I don't have any numbers to prove it, but I'd say the reason Linux users aren't freaking out is because the vast majority of them would've have disabled Secure Boot. In fact, many guides and videos from popular Youtubers[1] explicitly state to disable Secure Boot.
As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.
My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.
The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).
Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.
Why has it been broken? I’m running secure boot on all my machines with my own certs. It works fine.
Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.
Some laptops allow Custom Mode in UEFI setup menu. Then you can clear these keys and load your own. On Linux etc. you can that way enable secure boot without MS keys.
This is not an issue specific to Linux, Windows installations can be downgraded as well. As for the mechanism, UEFI devices, alongside key updates, also get revocation list updates.
Strangely I feel like I've never seen one of these. It would be needed after every major kernel / user land exploit. It would also need rollback protection on the motherboard itself so you couldn't just remove the updated keys / revocations.
In 2012, Windows 8 stopped booting on computers without UEFI secure boot. Hardware companies weren’t enthusiastic, but they couldn’t ignore Microsoft’s demand. Microsoft published the spec for how Windows 8 would handle secure boot, and that included the crypto key that will be expiring in September. Microsoft’s spec did actually have provisions for non-Microsoft operating systems.
Linux developers didn’t all agree about whether Linux needed to do anything about Microsoft’s plan, but ultimately a Red Hat programmer convinced enough people that it would be easier to follow Microsoft’s spec than to tell new users to “turn off secure boot” if they wanted to run Linux ( https://mjg59.dreamwidth.org/12368.html ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
No. I was there in 2012, Redhat's solution was the only solution which would have properly worked. Eventually, the infrastructure developed for measured boot due to these measures allowed Linux to use TPM in it's proper usage, and allowed sedutils and similar applications to be supported on linux.
You can load your own Secure Boot keys and sign your bootloader yourself; as for why the Microsoft ones are preloaded, probably because they're the only entity that interacts with all of these OEMs and had enough leverage over them to force Secure Boot adoption in the first place.
Thanks to the incredible combination of Lenovo and Nvidia, I cannot remove the Microsoft keys from my laptop. Not because Microsoft backdoored my computer, but because the Nvidia boot ROM is signed by an MS cert and that runs before you can access the UEFI setup.
I hope the firmware either doesn't check the expiry date or that the firmware itself has been upgraded, or several years worth of Thinkpad are about to stop booting in the near future.
It should be just "hey, do you trust this install media" -> "yes" -> boot key is automatically added at this step.
Instead the whole ecosystem is at microsoft whim
If it becomes this easy then Secure Boot just becomes Vista-era UAC. Sometimes making the security bypass an intentional act that requires some knowledge is a good thing. Most PC users, were their bootloader compromised and they saw such a screen on startup, would instantly press yes and forget about it within 5 minutes.
Not to say that having Microsoft as the custodian of the keys preloaded on all PCs is the optimal solution, but I don't think a token yes/no to add any random key on boot is a good idea either.
> What is the convincing reason that MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)?
For OEMs, presumably the stranglehold they have on them via Windows. For users, not much, but none of the ones making these decisions really care about that.
Nothing stops vendors from shipping additional keys, and several do - I've seen multiple laptops that included an Ubuntu signing cert (contrary to Canonical's recommendation)
The short answer is simply that nobody credible has offered to run such a service. The Linux Foundation investigated it and concluded that it was impractical to do so. Since secure boot rolled out we've seen a couple of pieces of malware that have explicitly attempted to bypass it (largely through vulnerabilities in Microsoft's bootloaders, ironically) which strongly implies that it's an obstacle to their goals rather than mere security theater.
It's not exactly new for Microsoft to slide themselves in somewhere and become the "standard" before anyone has really thought about how terrible their products are.
I mean, NSA-blessed or not, the way this happened was not some hidden conspiracy. It was in the open. The reason it happened is all of these machines are basically made to run Windows, so they need to have Microsoft keys. Microsoft was pushing for Secure Boot, for security and "trusted computing" (evil or good, depending on your PoV,) and open source complained that this is a way to lock in users to Windows, so the compromise choice was to have them sign a GRUB shim so that Linux could just as easily be run without enrolling your own keys.
Microsoft is the trusted party because they convinced hardware manufacturers to install their keys by default; that's it. A lot of commercial/industrial/pre-branded OEM hardware comes without Microsoft's keys, they're only there for the Windows Logo.
> Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot?
This would be pointless and erode the security of the system. Users who care can already remove Microsoft's root keys and enroll their own. There's a small corner case with UEFI Extensions / device firmware, but in this case a lightweight "sign everything" foundation would only serve to erode the security of the system. The problem space is completely orthogonal to website SSL and by and large simply good and not bad when properly configured.
> I also do not see a convincing reason it meaningfully improves security posture.
Secure boot paired with secure boot-sealed disk encryption massively reduces attack surface; with only Secure Boot-sealed keys (ie, BitLocker default), it reduces attack surface for the data on your disk to "post-boot authentication bypass or RCE" from "literally anyone or any piece of software who touches your computer or a disk that came out of it, ever." With keys sealed by Secure Boot and sealed or even just stretched by another mechanism (password, PIN, etc.), it reduces attack surface to "machine unlocked."
> MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)
I've been on Hacker News for an extremely long time and respect the community wish to avoid meta-discourse in general, but this kind of rubbish discourse with weird slurs and unfounded conspiracy theories is getting horrendous lately; I wish this site could more collectively move towards a productive curiosity rather than evidence-free statements based on arbitrary prejudice.
It needs to be said, this is what you get by "trusting" Microsoft.
There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.
The word from Red Hat is existing systems will continue to boot — presumably because they are time-stamped and counter-signed or because the dates are ignored entirely.
99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.
They've also had over a year to prepare for this so if Linux distros are only telling you now, that's on them.
IIRC UEFI firmwares do not check the expiry date, they don't care that the certificate has expired at all. There's no risk of any existing .efi binaries suddenly not loading.
The issue seems to be that Microsoft will refuse to sign anything new with the expiring certificate (which is correct behaviour), so any UEFI firmware that hasn't got the new certificate will refuse newly signed bootloaders.
I don't see anything wrong with this scenario, it's on distros to properly make sure they're distributing secure boot certificate updates.
Edit: Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
> Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
Why is that? RHEL own blog post described that RHEL is distributing dual signed shim by both 2011 and 2023 certificates, so that it works either way, only 2011 present or only 2023.
> 99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.
Well yea - as someone who has 0 understanding of why we need it, and only ever get greatly frustrated by it, I am pretty mad that people feel entitled to call my distro managers "that's on them"
They left out the steps to update it. I made a rough attempt at a document for this. [1] Please let me know if I missed a validation step. I have done this on six machines but they were all Linux. Not tested on BSD.
Archive [2] in the event I was too aggressive in blocking bots.
[Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.
[1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...
[2] - https://archive.is/ml3jv
[3] - https://www.reddit.com/r/archlinux/comments/1pvw6td/grub_shi...
FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
I actually did that on purpose since all browsers support brotli I risked the possibility someone might have disabled it with an add-on. I wanted to see how many bots that would break. It may not be the most logical process but I just use CanIUse [1] to see what supports Brotli. I ignore the Opera Mini block as they seem to support almost nothing.
[1] - https://caniuse.com/brotli
Ah, fair enough. Well Firefox should support Brotli by default, so it's probably something going on on my machine.
Nothing wrong with that. I think people should be able to disable anything they want. I doubt any commercial sites will do what I am doing. I use that little blog to test all manor of unorthodox things. That's why I listed the archive mirror, just in case.
I've seen commercial sites hard-code gzip content in all their responses regardless of the Accept headings. Probably just as fair to use Brotli these days.
Similarly, I've been using zopfli (gzip/unzip compatible) for png compression after quantization for db storage from 2-color (B/W) scans as it's directly compatible to the browser but winds up about 1/6 the original sized tiff. Not the best compression, had a discussion for a better compression, but required a wasm renderer to decompress as it isn't in the browser box.
More recent archive [1]
[1] - https://archive.is/dPFuq
Found this on one machine. Key expires in 5 days. System runs Linux only and has never booted Windows, ever. Secure boot may be off.
I had to vouch your comment, not sure what happened there. Something in your technical output must have triggered HN. One can use mokutil to see if Secure Boot is enabled after installing it. I assume the OEM installation or update of the BIOS must have included that cert but I am just guessing.
Thanks.
Just checked. Secure Boot is not enabled on any of my machines, which are Linux-only. Whew!
(I wonder if any of the ASUS subnotebooks I bought off eBay for minor embedded stuff have this problem. Have to power them up.)
My ASUS laptop had it enabled. I had to disable it as there just wasn't enough non volital memory to hold all the updates even after remove several EFI entries and resetting the BIOS. All my mini-PC's updated fine however. My Linux Protectli routers already had it disabled thankfully. They use Coreboot, unsure if that was a factor.
> The KEK updates are going out at ~98% success, and db update is ~99% success
glad to see the opt in fwupd analytics being so useful for something like this
Not envious of the running around contacting vendors they must of been doing on such short order.
I saw 2-3 flavors of this news. None of them include a basic “how do I check if I need to do anything” guide that a linux newbie can do.
On my Fedora machine I was able to run
To check my secure boot keys. As long as there's 2023 Microsoft keys you should be fine. Otherwise, my understanding is that you just need to update your firmware, but please somebody correct me if I'm wrong.https://wiki.debian.org/SecureBoot/CAChanges#What_should_I_d...
Last time I installed Arch, I put Secure Boot in setup mode and enrolled by own keys. The idea of using someone else's keys seems absurd.
Do note that being able to completely remove MS keys is highly dependent on your mainboard. Not in the sense of if they allow you to do it (I think most if not all DIY boards allow you to), but if you will be able to boot afterwards.
I (soft?)bricked a mainboard and it doesn't want to boot anymore after I removed the MS keys. The worst part is, that it has a dualBIOS and no active switch to change between them, only their own "I'll change when I see issues"... well you can guess how well that worked out (and I am not able to get it to clear CMOS for some reason).
I've honestly always kept secure boot off on my machines (which also use Arch). I don't really feel like the level of threat from someone (or me, by accident) booting an image I don't want them to on my hardware is particularly worth the hassle it brings; nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
> nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
The threat model secure boot was actually designed to protect against is not someone else booting a different OS in your hardware; the real threat model it protects against is malware loading before the OS can start the antivirus. With UEFI, malware could in theory run even when you boot from your OS install media, making it much harder to detect and remove. That's the reason installing your own secure boot key requires a one-time confirmation through a physical input device (which malware can't fake).
Unfortunately, protecting against that threat model (persistent malware loading before the OS) created another threat model, which IMO is a bigger worry: that you could one day be forbidden from running your own OS in your own devices. AFAIK, there have already been a few devices where secure boot cannot be disabled, your own secure boot keys cannot be enrolled, and the "third party" (aka "non-Microsoft") key is not available.
I'm inclined to agree when it comes to desktops or servers. However I feel like a laptop needs better security, including secure boot and full disk encryption, since you could lose it and cannot be sure what it went through even if you get it back somehow.
I do use FDE on my laptop, but not secure boot. I guess I'm not particularly concerned about whether someone will load a kernel onto my boot partition and then return the laptop to me. I could always just clear out my boot partition and then set it up manually again from an Arch USB, and that would still be far less hassle than turning in secure boot.
> triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update.
I didn't even realize this could be a problem despite the next paragraph implying it's very well known.
Discussed at the time (of the article):
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs.
Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware).
https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you)
https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...
> he expiry date is enforced for signing new binaries
Does this means that updating my system kernel would fail or even break boot?
Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.
No, distros uses a shim binary that is less likely to need updates. If that shim needs an update (only signed with the new key) then we get into a situation where old machines will fail to boot it.
I don't have any numbers to prove it, but I'd say the reason Linux users aren't freaking out is because the vast majority of them would've have disabled Secure Boot. In fact, many guides and videos from popular Youtubers[1] explicitly state to disable Secure Boot.
As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.
[1] https://www.youtube.com/watch?v=_Ua-d9OeUOg&t=253
My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.
The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).
Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.
Why has it been broken? I’m running secure boot on all my machines with my own certs. It works fine.
Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.
numerous vulnerabilities in secure boot deployment over many years. e.g. https://arstechnica.com/security/2024/09/secure-boot-neuteri...
Well, it seems like keeping secure boot disabled was gonna help me in the future haha
I know it is not recommended but the options to have my own keys seemed a bit of a hack than a solution.
Some laptops allow Custom Mode in UEFI setup menu. Then you can clear these keys and load your own. On Linux etc. you can that way enable secure boot without MS keys.
Not all devices support it, so choose wisely.
How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?
This is not an issue specific to Linux, Windows installations can be downgraded as well. As for the mechanism, UEFI devices, alongside key updates, also get revocation list updates.
Strangely I feel like I've never seen one of these. It would be needed after every major kernel / user land exploit. It would also need rollback protection on the motherboard itself so you couldn't just remove the updated keys / revocations.
[dead]
[dead]
[flagged]
In 2012, Windows 8 stopped booting on computers without UEFI secure boot. Hardware companies weren’t enthusiastic, but they couldn’t ignore Microsoft’s demand. Microsoft published the spec for how Windows 8 would handle secure boot, and that included the crypto key that will be expiring in September. Microsoft’s spec did actually have provisions for non-Microsoft operating systems.
Linux developers didn’t all agree about whether Linux needed to do anything about Microsoft’s plan, but ultimately a Red Hat programmer convinced enough people that it would be easier to follow Microsoft’s spec than to tell new users to “turn off secure boot” if they wanted to run Linux ( https://mjg59.dreamwidth.org/12368.html ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
Red hat always creates problem in linux....
No. I was there in 2012, Redhat's solution was the only solution which would have properly worked. Eventually, the infrastructure developed for measured boot due to these measures allowed Linux to use TPM in it's proper usage, and allowed sedutils and similar applications to be supported on linux.
You can load your own Secure Boot keys and sign your bootloader yourself; as for why the Microsoft ones are preloaded, probably because they're the only entity that interacts with all of these OEMs and had enough leverage over them to force Secure Boot adoption in the first place.
Thanks to the incredible combination of Lenovo and Nvidia, I cannot remove the Microsoft keys from my laptop. Not because Microsoft backdoored my computer, but because the Nvidia boot ROM is signed by an MS cert and that runs before you can access the UEFI setup.
I hope the firmware either doesn't check the expiry date or that the firmware itself has been upgraded, or several years worth of Thinkpad are about to stop booting in the near future.
It should be just "hey, do you trust this install media" -> "yes" -> boot key is automatically added at this step. Instead the whole ecosystem is at microsoft whim
If it becomes this easy then Secure Boot just becomes Vista-era UAC. Sometimes making the security bypass an intentional act that requires some knowledge is a good thing. Most PC users, were their bootloader compromised and they saw such a screen on startup, would instantly press yes and forget about it within 5 minutes.
Not to say that having Microsoft as the custodian of the keys preloaded on all PCs is the optimal solution, but I don't think a token yes/no to add any random key on boot is a good idea either.
> What is the convincing reason that MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)?
For OEMs, presumably the stranglehold they have on them via Windows. For users, not much, but none of the ones making these decisions really care about that.
Nothing stops vendors from shipping additional keys, and several do - I've seen multiple laptops that included an Ubuntu signing cert (contrary to Canonical's recommendation)
The short answer is simply that nobody credible has offered to run such a service. The Linux Foundation investigated it and concluded that it was impractical to do so. Since secure boot rolled out we've seen a couple of pieces of malware that have explicitly attempted to bypass it (largely through vulnerabilities in Microsoft's bootloaders, ironically) which strongly implies that it's an obstacle to their goals rather than mere security theater.
It's not exactly new for Microsoft to slide themselves in somewhere and become the "standard" before anyone has really thought about how terrible their products are.
Nor is it Microsoft exclusive. Google and Apple have the same modus operandi.
It's not Microsoft exclusive, but they are over-represented even in the group of "big evil tech companies".
I mean, NSA-blessed or not, the way this happened was not some hidden conspiracy. It was in the open. The reason it happened is all of these machines are basically made to run Windows, so they need to have Microsoft keys. Microsoft was pushing for Secure Boot, for security and "trusted computing" (evil or good, depending on your PoV,) and open source complained that this is a way to lock in users to Windows, so the compromise choice was to have them sign a GRUB shim so that Linux could just as easily be run without enrolling your own keys.
Microsoft is the trusted party because they convinced hardware manufacturers to install their keys by default; that's it. A lot of commercial/industrial/pre-branded OEM hardware comes without Microsoft's keys, they're only there for the Windows Logo.
> Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot?
This would be pointless and erode the security of the system. Users who care can already remove Microsoft's root keys and enroll their own. There's a small corner case with UEFI Extensions / device firmware, but in this case a lightweight "sign everything" foundation would only serve to erode the security of the system. The problem space is completely orthogonal to website SSL and by and large simply good and not bad when properly configured.
> I also do not see a convincing reason it meaningfully improves security posture.
Secure boot paired with secure boot-sealed disk encryption massively reduces attack surface; with only Secure Boot-sealed keys (ie, BitLocker default), it reduces attack surface for the data on your disk to "post-boot authentication bypass or RCE" from "literally anyone or any piece of software who touches your computer or a disk that came out of it, ever." With keys sealed by Secure Boot and sealed or even just stretched by another mechanism (password, PIN, etc.), it reduces attack surface to "machine unlocked."
> MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)
I've been on Hacker News for an extremely long time and respect the community wish to avoid meta-discourse in general, but this kind of rubbish discourse with weird slurs and unfounded conspiracy theories is getting horrendous lately; I wish this site could more collectively move towards a productive curiosity rather than evidence-free statements based on arbitrary prejudice.
Because they were the only party competent enough to run a PKI (which is 95% policy) while Linux distros still can't agree on a single boot loader.
shim didn't exist at first. Linux was planning to go without until Red Hat's hand was forced likely because their paying customers demanded it.
It's actually largely because I demanded it, our customers weren't paying attention at all - Fedora was going to be hit much worse than RHEL
It's for your own security, duh ;)
> presumably NSA-blessed
You have your answer
It needs to be said, this is what you get by "trusting" Microsoft.
There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.
I disagree that there is no need for secure boot for Linux?
Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.
You might argue that you don't care about this, but some people such as myself do!
> Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.
By trusting another chain of trust and firmware binary blobs involved in booting your PC.
Secure boot exists only as one of the puzzle pieces for remote attestation for MS and trusted OEMs, nothing to do with your security.
If you want yourself to be the root of trust, you CAN generate and use your own keys for secure boot.
>By trusting another chain of trust and firmware binary blobs involved in booting your PC.
So what? I'm still preventing a random person from tampering with my bootloader?
I don’t know why we ended up trusting microslop. Red Hat implemented it for the sake of convenience causing all these issue.
The word from Red Hat is existing systems will continue to boot — presumably because they are time-stamped and counter-signed or because the dates are ignored entirely.
99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.
They've also had over a year to prepare for this so if Linux distros are only telling you now, that's on them.
IIRC UEFI firmwares do not check the expiry date, they don't care that the certificate has expired at all. There's no risk of any existing .efi binaries suddenly not loading.
The issue seems to be that Microsoft will refuse to sign anything new with the expiring certificate (which is correct behaviour), so any UEFI firmware that hasn't got the new certificate will refuse newly signed bootloaders.
I don't see anything wrong with this scenario, it's on distros to properly make sure they're distributing secure boot certificate updates.
Edit: Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
> Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
Why is that? RHEL own blog post described that RHEL is distributing dual signed shim by both 2011 and 2023 certificates, so that it works either way, only 2011 present or only 2023.
> 99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.
Well yea - as someone who has 0 understanding of why we need it, and only ever get greatly frustrated by it, I am pretty mad that people feel entitled to call my distro managers "that's on them"