Tell HN: Microsoft SecureBoot "Breaking" Changes, Today's Milestone
https://www.bleepingcomputer.com/news/microsoft/windows-11-kb5041585-cumulative-update-released-with-fixes-new-features/
https://www.bleepingcomputer.com/news/microsoft/windows-10-kb5041580-update-released-with-14-fixes-security-updates/
Among other things:
>older Linux ISO images might not boot
From what I understand this is the next phase from Microsoft in the gradual rollout of a functional "blacklist" of original Microsoft-signed keys that all UEFI motherboards shipped with until not that long ago. Until the keys became compromised. These were built-in Microsoft-signed keys which were available for something like Linux to use when Microsoft SecureBoot was enabled on the motherboard, if the OS was willing to go the extra mile and obtain its own Microsoft-signed key according to the strict Microsoft process. Which Linux did eventually, but it took a year or two, until then you mainly needed to disable SecureBoot before you could boot Linux. After that "finally" Linux was able to boot on any UEFI PC having SecureBoot enabled, using a key which is pre-existing on every motherboard, without having to insert its own Linux key into the firmware beforehand. Adding Linux-specific SecureBoot Keys can be good to avoid because it requires making changes to machine keys, and does alter the firmware, but this also is a well-known valid UEFI alternate approach used by distros that did not want to have any Microsoft-signed anything.
Ideally a USB drive or SSD with Linux properly installed should smoothly boot on any UEFI motherboard, especially on motherboards other than the one the drive was attached to when Linux was installed. Which means on a different PC you may need to use the firmware interface itself [0] to select the proper EFI folder to boot from, but with Linux having its own Microsoft-signed key it's supposed to be just booting right up when SecureBoot is enabled using the same key built into every motherboard originally. As allowed for by the hardware manufacturers and UEFI standardizers, this was supposed to put Linux on equal footing with Windows since Windows has its own non-Linux SecureBoot keys built into every motherboard, from the time UEFI was first introduced to consumers along with "SecureBoot".
Anyway, this is the next step in replacing the compromised firmware keys from Microsoft. Until now with Windows you would have been expected to optionally initiate this blacklist procedure yourself, with this update it will occur to the PC by default.
In 2023 Ubuntu launched its equivalent firmware key replacement:
https://discourse.ubuntu.com/t/sbat-revocations-boot-process/34996
So it might have already happened to your Linux PC by default.
However at this point, today's Windows patch is apparently only being applied to plain Windows PCs:
>This SBAT update will not apply to systems that dual-boot Windows and Linux
I believe a further milestone will be encountered where it will close this door eventually.
So I would think this is a good time to see where you stand with older ISOs and bootable drives which may need "re-shimming" of some sort before they will boot like they used to do when SecureBoot was enabled :\
.
[0] Sometimes needed when there is no bootentry in the firmware that is normally placed by the OS install process.
6 comments
[ 3.4 ms ] story [ 14.0 ms ] threadThankfully, I solved the problem by removing Windows a couple of years ago. It now lives in a rarely used VM.
I've never had this, but I guess if you have it installed to /efi/boot/bootx64.efi it would be no surprise that Windows updates replace it.
So when dual booting you shouldn't use bootx64.efi for this reason and I'm pretty sure most distributions don't and instead install to /efi/<distribution name>/
That's why i disable "SecureBoot". It does not bring any security.
If you have a gaming board: Firmware integrity checks are mostly easy bypassable.
If you use a distro's default bootloader scheme: You can compromise the OS pre-login.
The CA that signed the shim, the Microsoft 3rd party CA, sogned all kinds of crap that lets you run whatever you want from that.
The whole shim thing is not about security but having stuff boot smoothly without screwing with bios settings.
If you want it to give you integrity, then you need to roll your own keys and make sure the firmware has no signature check bugs letting one bypass signature checks.
All this is orthogonal to self sovereign systems.
On Intel thats gone. You can't have a secure and sovereign firmware game without extreme extra effort.
The whole secureboot roll your own keys is the next best thing of harm reduction.
If we had some way of making the system actually static and separate from userdata. And a way to boot that prevents any persistent executable code from the userdata part from running. So as to have a clean state. From that on we could bind that state to unlock signing keys to sign the next version of the booted stuff. Then we could have nice security properties minus whatever is bad in the Intel TCB.
Compromise to root would actually be nicely reversible.
Immutable distros exist. But they are not there yet in terms of conditional readonly-ness.