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

61–70 of 272 posts

Re: Linux and Secure Boot certificate expiration

#61

Post by flexagoon »

fsflover wrote: post #50
froh wrote: 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?

Consider using Heads with TPM and Librem Key to detect possible compromise of your boot stage. It doesn't obey MS but you.

With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.

Re: Linux and Secure Boot certificate expiration

#62

Post by xyst »

Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors.

Seems disabling these "features" is nearly impossible as well.

[1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine

[2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...

Re: Linux and Secure Boot certificate expiration

#63

Post by jeroenhd »

crinkly wrote: post #2

So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.

If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires.

If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires.

If users do update their systems and software, Grub will keep working.

Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.

Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.

Re: Linux and Secure Boot certificate expiration

#64

Post by jeroenhd »

Artoooooor wrote: post #13

Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".

Just disable secure boot if you can't update the certificate. You can still use your computer.

Re: Linux and Secure Boot certificate expiration

#65

Post by jeroenhd »

I wonder what my laptop will do soon.

Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.

Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.

Re: Linux and Secure Boot certificate expiration

#66

Post by flexagoon »

ACCount36 wrote: post #49
froh wrote: 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?

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 certs from your device, HTTPS sites will stop working. However, nothing is stopping you from adding your own keys to the system and signing your own software with it.

> happens with every other smartphone, gaming console, car, and even some PCs

How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?

> the target of this attack is user freedom and choice.

Which is exactly why users have the freedom and choice to just disable Secure Boot?

Re: Linux and Secure Boot certificate expiration

#67

Post by blkhawk »

repstosb wrote: post #34
blkhawk wrote: post #21

Earlier quoted context omitted.

As a Linux-only gamer since 2019 I wonder what kids games you are talking about?

There are things like Roblox that are really only usable under Windows due to a perverse idea of what "anti-cheat" should look like.

ah, I almost mentioned roblox but checking protondb it has gold status. So it should work?

Re: Linux and Secure Boot certificate expiration

#68

Post by semi-extrinsic »

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…

> Really it seems like having any expiry date for these certificates is a mistake.

Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.

Re: Linux and Secure Boot certificate expiration

#69

Post by the8472 »

ChocolateGod wrote: post #23
mormegil wrote: post #17

Earlier quoted context omitted.

Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?

Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).

With a UKI the initramfs gets signed too, doesn't it?

Re: Linux and Secure Boot certificate expiration

#70

Post by Dead_Lemon »

ozgrakkurt wrote: post #38
nottorp wrote: post #31

Earlier quoted context omitted.

You'd have control over what boots on your computer then...

That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon

Secure boot doesn't stop user-space malicious activity.

I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.

Post reply on HN