Tell HN: Microsoft SecureBoot "Breaking" Changes, Today's Milestone

[fuzzfactor]

For today's patch Tuesday these articles outline the updates and make good mention of the SecureBoot Advanced Targeting (SBAT) component:

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.

[bradley13]

Using the shim for dual-booting was a pain, not least because Microsoft updates periodically removed it.

Thankfully, I solved the problem by removing Windows a couple of years ago. It now lives in a rarely used VM.

[ChocolateGod → bradley13]

> Using the shim for dual-booting was a pain, not least because Microsoft updates periodically removed it.

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

[OSI-Auflauf]

If firmware not buggy: If Secureboot is set up to use keys which never signed any bootloader that lets you modify the system pre-login.: Then it kind of matters.

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.

[OSI-Auflauf → OSI-Auflauf]

Many surface brand devices had a toggle in the bios for something like "security level" for years. Which is a switch between Windows signing CA only and Windows signing CA + 3rd party CA. The latter allows shim distros to boot. You can still set your own keys on them.

[hulitu]

> Tell HN: Microsoft SecureBoot "Breaking" Changes, Today's Milestone

That's why i disable "SecureBoot". It does not bring any security.

[uncharted9]

Does this affect Fedora and Ubuntu, which run fine with Windows dual-boot and secure boot enabled?