Benefits for LWN subscribers
The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. 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. 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.
Mateus Rodrigues Costa raised the issue on the Fedora devel mailing list on July 8. He had noticed a warning that came with "this month's Windows 11 cumulative update"; it talked about Secure Boot certificates that are scheduled to expire starting in June 2026. Those particular certificates are separate from the one used for shim, which expires much sooner. In any case, the problem of certificate expiration is one that the Linux world will need to tackle.
The situation is rather complicated. Daniel P. Berrangé pointed to a page at the Linux Vendor Firmware Service (LVFS) site that describes it. LVFS is the home of fwupd and other tools that are used to update system firmware from Linux. LVFS and fwupd are the subject of an LWN article from 2020.
There are multiple moving parts to the problem. In order to do a Secure Boot into the Linux kernel, the UEFI boot process requires the first-stage bootloader to be signed with a key in the firmware database that has not expired. Those keys are contained in certificates, which have other information, such as an expiration date and signature(s). The certificate expiration should largely only be a problem when installing a new distribution on a Secure Boot system; the shim that gets installed will have distribution-specific keys and can act as the root of trust for running other programs (e.g. GRUB) using those keys.
Currently, shim is signed with a Microsoft key from 2011 that expires on September 11. Past that point, installation media will no longer boot unless it has an updated shim that is signed with the Microsoft 2023 UEFI key for third-parties (which is different than the specific key mentioned in the Windows update). Any installed distribution should have a bootloader signed with its own key that will continue to boot.
But there are lots of systems out there with a firmware database that lacks Microsoft's new key, some have both old and new keys, while there are likely some that only have the new key and cannot Secure Boot Linux installation media at all at this point. Vendors can (and hopefully most will) provide firmware updates that add the new key, and installation media can be created with a shim signed by it, but those updates have to be installed on systems. That's where LVFS and fwupd come in.
LVFS is a repository of vendor-firmware updates of various sorts, which fwupd and other tools can use to install the pieces that are needed into the firmware from Linux. Berrangé noted that older versions of fwupd were unable to solve all of the problems, "but recent releases have been enhanced to handle the updates that Linux users will need to see, which should mitigate the worst of the impact". There may still be a bit of a bumpy ride, however: "Users should be 'aware' of the potential for trouble, but hopefully the worst of the 'worry' part is handled by the OS vendors and maintainers."
LVFS creator and maintainer Richard Hughes agreed, noting that there were various ways that people's systems would be able to get updated Secure Boot functionality. A full firmware update might be provided by the vendor, which would (presumably) add the new database, including the new Microsoft key. Another avenue would be a "key exchange key" (KEK) update, which is a vendor-specific key that is signed by the Microsoft key; it can be used by fwupd to update the database with the new key. But there are some caveats:
The KEK updates are going out at ~98% success, and db update is ~99% success -- but even 1% multiplied by millions of people is a fair few failures to deploy -- the "failed to write efivarfs" thing. What fixes it for some people is rebooting and clearing the BIOS to factory defaults -- this has the effect of triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update. The older your BIOS the more likely you are to hit this.
Hughes is referring to a known problem with space for new EFI variables.
For systems where the vendor provides no updates, disabling Secure Boot may be the only option to allow a new install. In a few short months, all existing installation images and media will not be installable with Secure Boot—that may already be true for systems that only have the new key. Secure Boot installation just got that much more complicated.
Beyond that, though, is the possibility of mistakes or problems with the vendor updates. Hughes pointed out that at least one manufacturer has lost access to the private part of its platform key (PK), which is a vendor-specific key burned into the hardware when it is made. That means the platform keys in the hardware need to be changed, which is uncharted water and "a terrible idea from an attestation point of view". In addition, as Gerd Hoffman pointed out, the KEK update process is new as well: "a KEK update has never happened before so there are chances that bios vendors messed up things and updating the KEK doesn't work".
The thread has multiple reports on the Secure Boot certificates on various hardware models, as well as reports of updates to the KEK and database. One thing that is not entirely clear is whether the firmware implementations will actually enforce the expiration date on the 2011 key. A working system with a functional trust-chain based on that key might continue to work with a shim signed with that key, even after September. Any shim updates, for, say, security problems, would not be able to be signed with the old key, however—Microsoft will not sign anything using the expired key. That may lead to a "solution" of sorts, as Adam Williamson said:
In theory wouldn't we also have the option to ship an old shim for such cases? If the whole chain is old it should work, right? Of course, we'd then need some heuristic to figure out if we're on the old MS cert and install the old shim...
He said that it may not really make sense and users should just disable Secure Boot. Hoffman agreed with all of that, but pointed out the problem with shim updates: "Continuing running shim with known security bugs makes it [kinda] pointless to have secure boot turned on".
All in all, it seems like the Linux world is doing the best it can under the circumstances—as is so often the case when it comes to hardware from vendors that mostly care about Windows. Given that the Secure Boot root-of-trust keys (both the platform key and the signing key) are under the control of vendors—Microsoft and the hardware makers—it is always going to be a bit of a struggle to keep up. Since older hardware is something that Linux and distributions explicitly support, while the other vendors have long since moved on to the latest shiny, it was clearly going to lead to some tension there. One can only hope that the ride is as smooth as it can be.
Instagram Engineering
Shopify Engineering