How OS Kernels Orchestrate UEFI Capsule Updates

Operating systems update system and device firmware by leveraging Unified Extensible Firmware Interface (UEFI) capsule updates orchestrated through the kernel. This process bridges user-space update utilities, the OS kernel, and the pre-boot firmware environment. By abstracting UEFI Runtime Services and the EFI System Partition (ESP), the kernel prepares firmware payloads, stages them in memory or on storage, and configures the system to apply these payloads securely during a warm reset.

Firmware Discovery and ESRT

Before orchestrating an update, the operating system inspects the EFI System Resource Table (ESRT). The ESRT is an EFI configuration table published by the system firmware during boot that enumerates every updatable component (such as the system BIOS, device controllers, and embedded controllers) via a unique GUID.

The kernel parses the ESRT at boot time and exposes this information to user space (for instance, via /sys/firmware/efi/esrt/ in Linux). User-space update managers, such as fwupd on Linux or Windows Update on Windows, query this interface to check current firmware versions and verify compatibility against available update binaries.

Staging the Capsule Payload

The kernel facilitates the handoff of the capsule payload using one of two primary pathways defined by the UEFI specification:

1. In-Memory Delivery via UpdateCapsule(): The kernel uses the UEFI Runtime Service UpdateCapsule(). Because capsules can be many megabytes in size, the kernel allocates physical memory and constructs a Scatter-Gather List (SGL) represented by a chain of EFI_CAPSULE_BLOCK_DESCRIPTOR structures. Each descriptor points to physical data blocks containing slices of the capsule payload.

   Once mapped, the kernel calls UpdateCapsule(), passing the physical address of the descriptor list and setting the CAPSULE_FLAGS_PERSIST_ACROSS_RESET flag. This flag tells the firmware to preserve these designated physical memory regions across a system reset.

2. Disk-Based Delivery (Capsule-on-Disk): Due to memory constraints and driver complexities associated with massive in-memory scatter-gather buffers across reboots, modern platforms frequently use Capsule-on-Disk. In this flow:

   • The kernel or user-space update tool writes the signed capsule file directly to the EFI System Partition under \EFI\UpdateCapsule\.
   • The kernel modifies the persistent UEFI variable OsIndications, setting the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit. This acts as a hardware flag notifying the firmware that an update is waiting on disk.

Execution Across the System Reset

After the capsule is staged, the operating system initiates a reboot using the UEFI ResetSystem() runtime service with EfiResetWarm or EfiResetCold.

During the subsequent boot sequence:

• The UEFI Security (SEC) and Pre-EFI Initialization (PEI) phases retain awareness of the staged capsule, either by reading the intact memory locations designated by the OS or by locating the payload on the ESP.
• Before the third-party OS bootloader or driver execution occurs, the Driver Execution Environment (DXE) phase verifies the cryptographic signature of the capsule against OEM public keys embedded within the firmware.
• If validation succeeds, the firmware flashes the target component, clears the staging flags and temporary files, updates the component status and version in the ESRT, and proceeds with the normal OS boot.