Linux users may face yet another hurdle related to Secure Boot when the Microsoft-signed key used by many distributions to support the firmware-based security feature expires on September 11, leaving users at the mercy of distribution from OEMs, and systems possibly not receiving a necessary firmware update.
As LWN reported (paywall) that Microsoft will stop using the expiring key to sign the shim in September. “But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen,” LWN said. “It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.”
The report said manufacturers could add support for the new key in a full firmware update or by updating the KEK database. The former assumes that manufacturers would be interested in distributing a firmware update for a wide variety of products so a small percentage of their users could use Secure Boot with a non-Windows OS; the latter is an unproven mechanism that isn’t guaranteed to work on all devices. Both seem likely to leave at least some people to figure out a solution on their own.
If you don’t care about boot chain attacks it isn’t bad at all.
If you do care about boot chain attacks it’s bad because it allows someone to replace things like the efi binaries, grub, or your kernel with backdoor-ed versions and there would be no way to detect this from the running system.
Secure boot checks for this stuff. You can read more here:
https://access.redhat.com/articles/5254641
But if secure boot happens to brick your system forever because of this expiring key thing, is that worse than a boot chain attack?
It won’t brick your system forever??? You just turn it off in your bios. Then you have no secure boot. Just like it was never there.
Shouldn’t a system that was set up with Secure Boot refuse to start if it were disabled? Otherwise there wouldn’t be any protection against these attacks.
I don’t think setting up the system again is a simple remedy to having problems with this feature.
It won’t refuse to boot. It’s just that any automatic metric based decryption won’t work.
If you are using a TPM to automatically unlock luks and also manually removed the password backup before hand you could lose your data forever. That is true.
But if you kept the password based decryption stuff you could still manually unlock stuff. Just like secure boot was never there.
The difference would be that there could be no secure attestation that the kernel count trust/use without secure boot.
Like secure boot is really cool on Linux if you learn about it. Like sbctl alone is great for verifying backups and stuff.
I recommend reading through the arch wiki if you want to learn more. It covers a lot of stuff. https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
Turning off secure boot wont turn off your TPM, it just turns off all the signature verifications. Your TPM still stores the decryption keys and you can still decrypt your data.
Now if you do a UEFI/BIOS update without disabling your encryption while using a TPM, and dont have password decryption as a backup, yes, you could potentially lose access to your data.
It won’t turn off your TPM, but if you’ve set it up correctly (by using PCR7), the TPM won’t allow decrypting your data without secure boot.
Exactly this. The people who designed secure boot and TPMs were not idiots. You can’t trick a properly set up TPM configured with secure boot in any realistic setup.