Top
Best
New

Posted by weaksauce 1 day ago

Linux and Secure Boot certificate expiration (2025)(lwn.net)
127 points | 66 commentspage 2
charcircuit 1 day ago|
How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?
Sateallia 20 hours ago|
This is not an issue specific to Linux, Windows installations can be downgraded as well. As for the mechanism, UEFI devices, alongside key updates, also get revocation list updates.
charcircuit 19 hours ago||
Strangely I feel like I've never seen one of these. It would be needed after every major kernel / user land exploit. It would also need rollback protection on the motherboard itself so you couldn't just remove the updated keys / revocations.
melon_tsui 16 hours ago||
[dead]
tsouth2 1 day ago||
[dead]
jmclnx 1 day ago||
It needs to be said, this is what you get by "trusting" Microsoft.

There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.

chlorion 1 day ago||
I disagree that there is no need for secure boot for Linux?

Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.

You might argue that you don't care about this, but some people such as myself do!

Cloudef 1 day ago||
> Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.

By trusting another chain of trust and firmware binary blobs involved in booting your PC.

Secure boot exists only as one of the puzzle pieces for remote attestation for MS and trusted OEMs, nothing to do with your security.

Borealid 1 day ago|||
If you want yourself to be the root of trust, you CAN generate and use your own keys for secure boot.
chlorion 1 day ago|||
>By trusting another chain of trust and firmware binary blobs involved in booting your PC.

So what? I'm still preventing a random person from tampering with my bootloader?

cute_boi 1 day ago||
I don’t know why we ended up trusting microslop. Red Hat implemented it for the sake of convenience causing all these issue.
naturalmovement 1 day ago|
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.

ChocolateGod 1 day ago||
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 wrong with this scenario, it's on distros to properly make sure they're distributing secure boot certificate updates.

Edit: Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.

winstonwinston 1 day ago||
> 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.

OsrsNeedsf2P 1 day ago||
> 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.

Well yea - as someone who has 0 understanding of why we need it, and only ever get greatly frustrated by it, I am pretty mad that people feel entitled to call my distro managers "that's on them"