Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux and Secure Boot certificate expiration (2025)

lwn.net

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Linux and Secure Boot certificate expiration (2025)

#51

Post by saghm »

drnick1 wrote: post #48
saghm wrote: post #40

Earlier quoted context omitted.

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.

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.

Re: Linux and Secure Boot certificate expiration (2025)

#52

Post by winstonwinston »

ChocolateGod wrote: post #46
naturalmovement wrote: post #35

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…

> 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.

Re: Linux and Secure Boot certificate expiration (2025)

#56

Post by mjg59 »

arcza wrote: post #5

[flagged]

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.

Re: Linux and Secure Boot certificate expiration (2025)

#57

Post by cesarb »

saghm wrote: post #40
drnick1 wrote: post #18

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.

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.

Re: Linux and Secure Boot certificate expiration (2025)

#58

Post by tombert »

expedition32 wrote: post #30
tombert wrote: post #7

Earlier quoted context omitted.

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".

Re: Linux and Secure Boot certificate expiration (2025)

#59

Post by mjg59 »

saghm wrote: post #41
arcza wrote: post #5

[flagged]

> 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)

Re: Linux and Secure Boot certificate expiration (2025)

#60

Post by mjg59 »

naturalmovement wrote: post #36
arcza wrote: post #5

[flagged]

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
Post reply on HN