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…
Linux and Secure Boot certificate expiration
101–110 of 272 posts
Re: Linux and Secure Boot certificate expiration
#102Earlier 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.
Re: Linux and Secure Boot certificate expiration
#103Earlier 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.
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
#104Earlier 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.
Re: Linux and Secure Boot certificate expiration
#105Earlier 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?
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
#106The 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?
Re: Linux and Secure Boot certificate expiration
#107Earlier 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…
Re: Linux and Secure Boot certificate expiration
#108It'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.
Re: Linux and Secure Boot certificate expiration
#109Earlier 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…
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
#110Earlier 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…
You can? Delete the default (ie Windows certs) and import your own.