Linux and Secure Boot certificate expiration [LWN subscriber-only content]
Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!
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. "
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.
... continue reading