Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

101–110 of 272 posts

Re: Linux and Secure Boot certificate expiration

#101

Earlier 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…

That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).

Re: Linux and Secure Boot certificate expiration

#102

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

> Every couple of years MS do an update that messes up multi-boot/dual boot IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.

The idea that MS should be able make orders that distros then have to follow is insane. If MS breaks something it absolutely is their fault.

Re: Linux and Secure Boot certificate expiration

#103

Earlier quoted context omitted.

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option. Does it matter? Is it mine? If yes, then it should my concern. But that is the entire problem with trusted computing and recent trends in general. Corps become operators, users are downgraded to consumers.

> I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.

That, and fear of antitrust enforcement. The only reason we're still allowed to disable secure boot, or enroll our own keys, is that alternative PC operating systems already existed and were popular enough, that attempting to restrict PCs to only run Microsoft-approved operating systems would raise serious antitrust concerns.

But we're still at a serious risk. Microsoft still has enough influence over PC manufacturers to dictate their hardware requirements, and it would only take them being less afraid of antitrust to require them to no longer allow an override. They are already making things harder with "Secured-core PCs" (https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...).

Re: Linux and Secure Boot certificate expiration

#104

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

> Every couple of years MS do an update that messes up multi-boot/dual boot IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.

So Windows installs something that brakes Linux boot. How are you supposed to boot Linux to install a fix? Am I expected to reboot into a different OS twice a day and check for updates? Am I slacking for not doing so?!

Re: Linux and Secure Boot certificate expiration

#105
post #19

Earlier quoted context omitted.

Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. S…

What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?

> What kinds of attacks was Secure Boot designed to mitigate?

Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.

Re: Linux and Secure Boot certificate expiration

#106

The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?

Set your clock to December, reboot, and see what happens.

Re: Linux and Secure Boot certificate expiration

#107

Earlier 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…

EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.

Re: Linux and Secure Boot certificate expiration

#108
post #12

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

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)

Re: Linux and Secure Boot certificate expiration

#109

Earlier quoted context omitted.

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.

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?

Re: Linux and Secure Boot certificate expiration

#110
post #44

Earlier quoted context omitted.

mind to elaborate? I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. the promise of secure boot and trusted computing is backdoor-free boot. what is in your eyes evil and garbage about that?

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs?

You can? Delete the default (ie Windows certs) and import your own.

Post reply on HN