41–50 of 70 posts
[flagged]
For OEMs, presumably the stranglehold they have on them via Windows. For users, not much, but none of the ones making these decisions really care about that.
I didn't even realize this could be a problem despite the next paragraph implying it's very well known.
[flagged]
You can load your own Secure Boot keys and sign your bootloader yourself; as for why the Microsoft ones are preloaded, probably because they're the only entity that interacts with all of these OEMs and had enough leverage over them to force Secure Boot adoption in the first place.
I hope the firmware either doesn't check the expiry date or that the firmware itself has been upgraded, or several years worth of Thinkpad are about to stop booting in the near future.
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.
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!
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.
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…
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"
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…
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.
Earlier quoted context omitted.
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!
> 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.
So what? I'm still preventing a random person from tampering with my bootloader?
Last time I installed Arch, I put Secure Boot in setup mode and enrolled by own keys. The idea of using someone else's keys seems absurd.
I've honestly always kept secure boot off on my machines (which also use Arch). I don't really feel like the level of threat from someone (or me, by accident) booting an image I don't want them to on my hardware is particularly worth the hassle it brings; nobody else should ever be using my machines in the first place, and if they are, I'm going to have larger issues than what OS they decide to try to boot.
Earlier quoted context omitted.
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!
> 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.
I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs. Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
Existing systems are going to continue to boot. The expiry date is enforced for signing new binaries, not for deciding whether an already signed binary is allowed to boot (barring buggy firmware). https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you) https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...
Does this means that updating my system kernel would fail or even break boot?