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.
Let's start with a quick overview of what Secure Boot is. It's part of the Unified Extensible Firmware Interface (UEFI) that has replaced the Basic Input/Output System (BIOS) on modern systems. (Although it's still often referred to as the BIOS by enthusiasts and manufacturers.) Microsoft's knowledge base article about the feature explains that it "is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the [manufacturer]."
It's up to manufacturers to make sure "the signature database (db), revoked signatures database (dbx), and Key Enrollment Key database (KEK)" are "stored on the firmware nonvolatile RAM (NV-RAM) at manufacturing time." The manufacturer then "locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, then generates a platform key (PK) [...] used to sign updates to the KEK or to turn off Secure Boot."
None of those requirements preclude the installation of non-Windows operating systems. Most devices ship with Microsoft's OS pre-installed, however, which means installing something else first requires someone to disable Secure Boot. (Which assumes they're aware of the existence of the UEFI/BIOS, how to navigate it, and how to change its boot settings.) The question then becomes whether or not the installed OS allows Secure Boot to be re-enabled after it's been installed alongside or instead of Windows.
That leaves operating system distributors with a decision to make: omitting Secure Boot support entirely; expecting users to generate and sign their own keys; or finding a way to use the Microsoft-controlled db, dbx, and KEK to enable Secure Boot in their own systems. NetBSD, OpenBSD, and some of their more esoteric counterparts settled on the first option, while some Linux distributions and FreeBSD opted for the third by using a "shim" to build their Secure Boot support on top of Microsoft's infrastructure.
Now that we have that out of the way: 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.
All this for a feature with numerous vulnerabilities that have been both widespread (see: BootHole, BlackLotus, both PDFs) and limited to motherboards from specific manufacturers (see: MSI, Gigabyte). Addressing the system's flaws isn't always a welcome development, either, since they have been exploited to allow people to install Windows 11 on systems lacking a Trusted Platform Module (TPM) 2.0, as they don't want to be stuck on Windows 10 but also don't want to buy new hardware.
It's easy to see the appeal of Secure Boot—making it more difficult to install bootkits should be a net positive. However, the looming hassle of dealing with this expiring key is just the latest in a series of frustrations that encourage people to either stick with Windows or disable Secure Boot entirely. Right now, many people opt for the former, but will that continue to be the case as the popularity of other platforms rises ahead of Windows 10's demise? And is Secure Boot, as it currently exists, prepared for that shift?
Follow Tom's Hardware on Google News to get our up-to-date news, analysis, and reviews in your feeds. Make sure to click the Follow button.
