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

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

261–270 of 272 posts

Re: Linux and Secure Boot certificate expiration

#261

Post by preisschild »

m4rtink wrote: post #116
preisschild wrote: post #110

Earlier quoted context omitted.

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

I think it is only required on x86 EFI machines due to some old antitrust rulings. Provided the firmware vendor actually implements it right. On ARM for example the hardware, including some hardware shipping with ARM version of Windows, does not need to provide the option to add custom certs and remove existing ones, so AFAIK in most cases it is not possible.

I think you can do the same in the Tianocore EDK2 ARM UEFI

But yeah, many ARM boards don't use open UEFI firmware

Re: Linux and Secure Boot certificate expiration

#262

Post by nullc »

riedel wrote: post #169
whatagreatboy wrote: post #8

Earlier quoted context omitted.

Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.

The EU should step in and make sure that any critical OS attestation is taken out of the hands of the big players. Look at GrapheneOS is being denied Google Play Integrity [1] on pretty much no grounds with large consequences. Such security infrastructure is to easily abused to put bias into the market. On the other hand funding is needed to professionally run this stuff. [1] https://discuss.privacyguides.net/t/graph…

"The EU should step in"

EU mandates any hardware sold will only boot software signed by EU private key, with signatures only provided to software including government spyware and passing a billion euro certification process.

"No not like that!"

Re: Linux and Secure Boot certificate expiration

#263

Post by nullc »

chabad360 wrote: post #51

It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone b…

There is hardware that requires drivers to even reach the bios. The drivers are signed with the MSFT key. And if you change to your own key you'll find you can't even get into the bios anymore.

Re: Linux and Secure Boot certificate expiration

#264

Post by tiberious726 »

somat wrote: post #132
nine_k wrote: post #9

Earlier quoted context omitted.

Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden. AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).

MS did not "Have" to be involved. The problem is that doing it right is hard, not hard as in "it was tricky to figure it out but once we did everything works" but hard as in "every single user now has an additional impossible to remember key they have to keep track of or they get locked out of their system", basically the mother of all support nightmares. so Microsoft took the easy(perhaps realistically, the only) wa…

Eh, that's basically what we have now with boards where you can delete the MS keys and enroll your own. Just with different defaults and no support nightmare

Re: Linux and Secure Boot certificate expiration

#265

Post by rurban »

ACCount36 wrote: post #33
sugarpimpdorsey wrote: post #16

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.

Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.

Trusted Computing is to trust the NSA with your computing. They need to have access, right? And since they cannot control all hardware vendors, they opted to control Microsoft instead, and forced UNIX to play ball.

Re: Linux and Secure Boot certificate expiration

#266

Post by hulitu »

jeroenhd wrote: post #122
RedShift1 wrote: post #97

Earlier quoted context omitted.

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…

UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementi…

> I'll take UEFI over BIOS any time if only because it finally solved dual booting.

With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.

Re: Linux and Secure Boot certificate expiration

#267

Post by hulitu »

hypercube33 wrote: post #107
RedShift1 wrote: post #97

Earlier quoted context omitted.

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.

> EFI was part of the itanium culture at Intel

That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?

Re: Linux and Secure Boot certificate expiration

#268

Post by hulitu »

nirui wrote: post #47
mkj wrote: 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…

I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too? And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft. However, I think if Microsoft REALLY care about security, they should not let application installed on their system…

> However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user

Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.

Re: Linux and Secure Boot certificate expiration

#269

Post by hulitu »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

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

> Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?

Can someone give a _rational_ reason about why Google, Microsoft, Let's encrypt, Go lDaddy, Cloudfare etc. shall be "trusted" as opposed to "Achmed used cars and certificates" ?

Re: Linux and Secure Boot certificate expiration

#270

Post by hulitu »

danudey wrote: post #138
flomo wrote: post #18

Earlier quoted context omitted.

Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.

Can easily imagine companies like Dell selling you a system with Ubuntu preinstalled but without Windows signing keys so you can't run Windows on an Ubuntu laptop (or vice-versa) with Secure Boot on an unmodified system. Not out of malice, necessarily, but at least incompetence. Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system that suppo…

> Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system

No. See certificate expiration.

Post reply on HN