Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

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.

View on HN

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...

> he expiry date is enforced for signing new binaries

Does this means that updating my system kernel would fail or even break boot?

No, distros uses a shim binary that is less likely to need updates. If that shim needs an update (only signed with the new key) then we get into a situation where old machines will fail to boot it.

Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.

I don't have any numbers to prove it, but I'd say the reason Linux users aren't freaking out is because the vast majority of them would've have disabled Secure Boot. In fact, many guides and videos from popular Youtubers[1] explicitly state to disable Secure Boot.

As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.

[1] https://www.youtube.com/watch?v=_Ua-d9OeUOg&t=253

My very recent story with libvirt and secureboot resulted in blanket disabling of secureboot as part of the preparation for creation of VMs.

The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).

Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.

Why has it been broken? I’m running secure boot on all my machines with my own certs. It works fine.

Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.

numerous vulnerabilities in secure boot deployment over many years. e.g. https://arstechnica.com/security/2024/09/secure-boot-neuteri...

Reply on news.ycombinator.com