Better Firmware Updates in Linux* Using UEFI Capsules

There’s a new firmware update feature being proposed for Fedora 23, thanks to UEFI 2.5 and another set of obscure acronyms. Let’s take a minute to examine UEFI Capsule and understand why it’s a huge improvement over today’s non-standard update processes. Hopefully I can do that without resorting to puns based on pills or medical references.

Update Capsule is a UEFI Runtime function that passes information to the firmware. The most common use of Update Capsule is updating the firmware FLASH or for the OS to preserve information across a system reset. The caller sets a flag, with the surprisingly descriptive name CAPSULE_FLAGS_PERSIST_ACROSS_RESET, that indicates the firmware should process capsules found in memory after system reset, otherwise firmware processes the capsules immediately.

Download, reset, update. If this sounds like updates in Microsoft Windows* … well, that’s because it is. “Model Based Servicing” (MBS) was introduced in Microsoft Windows 8, but only for a select set of systems implementing ESRT. If you own a Microsoft Surface or Surface Pro, this is how you get firmware updates bundled with the Windows Update process. Leveraging standards allows a similar model to be adopted on any OS booting with UEFI.

The firmware driver package contains a firmware update payload, which is passed to UEFI firmware via the Update Capsule function. By processing the capsule after reset, the system firmware is responsible for authenticating the capsule and performing the update. If the capsule payload has been compromised or doesn’t apply to this system, the firmware can reject the update and avoid corruption. Firmware is essential to the platform’s root-of-trust, so it’s in the best position to securely update itself.

OS-based firmware update utilities have been around for years, but they’re typically proprietary tools built by the OEM or BIOS vendor that rely on unspeakable acts of SMM so the OS doesn’t freak out when a user-level application tries to rewrite several megabytes of memory at a fixed location. The model for updating firmware from the OS looks a lot like virus/malware behavior, plus everyone’s already a bit nervous about firmware code executing in SMM.

UEFI Capsule doesn’t really care about the payload, but it’s a standard way for the OS to stage updates for the firmware to process. The firmware makes a boot time decision if the capsule should be applied, which can be based on integrity checks or other platform parameters.

UEFI described two other assets related to the firmware update process … FMP & ESRT. The UEFI Firmware Management Protocol (FMP) abstracts device firmware management, including identifying firmware image versions and programming the new image. The EFI System Resource Table (ESRT) is an optional mechanism for identifying device and system resources with updatable firmware. Each ESRT entry describes a resource that can be targeted by a firmware capsule update, and reports status of the last attempted update (nice to know if that fails). Combining FMP & ESRT with UEFI Capsule creates an environment for simplifying platform and peripheral firmware updates.

All of this is really important for Linux* systems running UEFI. Update Capsule moves firmware programming out of the OS utility domain, so manufacturers don’t have to create an update program for every distribution. Keeping platform firmware updated is a great defense against firmware attacks, and standard Linux support for UEFI Capsule opens this up to a wider set of users.


For more complete information about compiler optimizations, see our Optimization Notice.