How UEFI Capsule Updates Flash BIOS Firmware

UEFI capsule updates provide a standardized, secure mechanism that allows modern operating systems to deliver and initiate motherboard and component firmware updates directly from user space. By passing a cryptographically signed binary payload to the system firmware via standardized interfaces, the operating system stages the update so that the UEFI platform can verify and apply it during the next system reboot. This process eliminates the traditional need for users to manually enter BIOS/UEFI setup utilities, boot from external flash drives, or use operating-system-level direct hardware flashing tools.

The Foundation: The EFI System Resource Table (ESRT)

Before an update occurs, the operating system must understand what hardware can be updated. During system boot, the UEFI firmware publishes the EFI System Resource Table (ESRT) into system memory.

The ESRT provides the operating system with a list of updatable components (such as the system BIOS, embedded controllers, or device firmware), their globally unique identifiers (GUIDs), the currently installed firmware versions, and the status of previous update attempts. Operating systems like Windows (via Windows Update) or Linux (via fwupd and the Linux Vendor Firmware Service) read this table to determine whether newer firmware versions are available.

Staging the Capsule Payload

A capsule is a self-contained binary package consisting of a standard UEFI capsule header followed by the vendor-specific firmware payload. The header contains metadata, including the target device GUID, flags, and the total size of the capsule.

When an operating system triggers a firmware update, it delivers the capsule to the firmware through one of two methods:

  1. UEFI Runtime Services (UpdateCapsule): The OS invokes the standard UpdateCapsule() API provided by UEFI runtime services, passing the capsule memory addresses directly to the firmware before initiating a system restart.
  2. Disk-Based Capsule Staging: Because large firmware binaries can exceed available contiguous runtime memory, the OS more commonly copies the capsule binary to a reserved directory on the EFI System Partition (ESP), typically under \EFI\UpdateCapsule\. The OS then sets specific non-volatile UEFI variables (such as OsIndications) to flag that a capsule is waiting for processing on the next reboot.

Pre-Boot Verification and Execution

Once the system restarts, it does not immediately boot into the operating system. Instead, the UEFI boot flow intercepts the staged capsule during the early boot phase:

  1. Detection: The UEFI PEI (Pre-EFI Initialization) or DXE (Driver Execution Environment) stage detects the capsule in physical memory or retrieves it from the EFI System Partition.
  2. Cryptographic Authentication: Before any flashing occurs, the existing platform firmware checks the capsule's digital signature against root keys embedded permanently within the platform (such as in write-protected flash or fused hardware). If the signature is invalid, corrupt, or downgraded (if anti-rollback protections are active), the update aborts immediately, and an error code is logged to the ESRT.
  3. Execution: Once verified, the platform transitions into a dedicated update mode. The capsule loader passes the verified image to the specific flashing driver or hardware engine.

Flashing the Non-Volatile Memory

During the flash stage, the firmware component directly communicates with the target storage medium, usually the SPI NOR flash chip hosting the BIOS, or a microcontroller handling an embedded controller (EC). Because this occurs in the single-threaded, isolated UEFI pre-boot environment, there is no risk of software interference, race conditions, or access conflicts caused by a running operating system.

When the write process finishes, the firmware clears the pending capsule flags from non-volatile storage, updates the version number in the ESRT, and issues a warm or cold reset. The system then boots normally into the operating system with the new firmware active.