News Microsoft signing key required for Secure Boot UEFI bootloader expires in September, which could be problematic for Linux users

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
I'm pretty skeptical of this article's claim that you need a firmware update (UEFI/BIOS update) to address this. You should be able to just enroll the new certs/keys yourself through the UEFI interface. You could, presumably, instead create a (temporary) Windows install and run the steps here: https://techcommunity.microsoft.com...g/updating-microsoft-secure-boot-keys/4055324

I admit I have not tried this myself, but I did do something similar back when I ran a more esoteric version of Linux. It didn't work out of the box with secure boot (the way Ubuntu, etc., do), but all I had to do is enroll the bootloader via the UEFI and I was good to go.

Edit: Ended up enrolling the new MS 2023 KEK just to try it out. Was pretty quick and easy; admittedly I don't really know how to test it, but it seemed to have work just fine. Used the cert listed in section 1.5 here https://learn.microsoft.com/en-us/w...ation-and-management-guidance?view=windows-11
The issue is not with loading drivers but the hardware itself. So yes a firmware update is needed regardless of which OS you are running.
If your manufacturer has not got an update method you have the same issue.
 
I can't see how it could work without it. Secure boot relies on the ability to validate integrity of files or media via checksums signed with digital signatures: that's basic PKI crypography and requires at least one initial CA present upon boot.

Of course managing that initial CA and delegating some stuff to others can and is being done, but the fact that those initial CAs are being managed by Microsoft, doesn't just irk other nations: even the hyperscalers prefer to manage all that on their own and inject their own firmware and/or TPU designs.

That's my understanding, too, but without an initial root CA the firmware trusts implicitly, there is no way to validate those checksums and distinguish between secure and insecure data or code, rendering secure boot unable to do its job and at best disabled. In a worst case scenario the hardware is trash if things with key management go wrong.

And that is typically the reason vendors find it hard to resist some backdoor of their own for these edge cases 😎
If you choose to load your own certs/keys, you are deciding who to trust and you take on the responsibility of validating the keys. As alluded to in this very article, you can start from scratch and bootstrap the whole thing by enrolling your own, self-generated platform key. You can find sample instructions for doing so here https://wiki.archlinux.org/title/Un...are_Interface/Secure_Boot#Using_your_own_keys

You don't need to do the full nuclear option though, and could instead just selectively enroll keys as required. It's not uncommon for vendors (particularly in the open source community) to post their public keys and/or hashes of their software in well-known locations (their own sites, github page, etc.), so that is one simple way to be reasonably confident the keys or binaries you're enrolling are legit.
 
Last edited:
The issue is not with loading drivers but the hardware itself. So yes a firmware update is needed regardless of which OS you are running.
If your manufacturer has not got an update method you have the same issue.
Not really sure what you're trying to say here, you don't seem to actually address anything I said in my comment. I didn't mention drivers at all. As I said, you can enroll new secure boot keys without having to update FW, meaning you can enroll the new MS key without new FW.