How UEFI Applies CPU Microcode Updates at Boot

CPU microcode updates are hardware errata patches loaded into a processor's volatile static RAM (SRAM) every time a system powers on. During the earliest phases of a UEFI boot sequence—specifically the Security (SEC) and Pre-EFI Initialization (PEI) phases—the firmware reads microcode binary containers from the flash ROM and writes them to the processor via architecture-specific Model-Specific Registers (MSRs). Because microcode updates do not persist across reboots, this low-level handoff ensures that stability, security, and functional fixes are active before the UEFI initializes system memory or hands control to the operating system.

Location and Packaging of Microcode

Modern UEFI firmware images store microcode patches within distinct Firmware Volumes (FVs) on the motherboard's SPI flash memory. These updates are packaged as binary blobs containing a structured header, cryptographic signatures, target CPU flags, stepping IDs, and the encrypted payload itself. During the build of the UEFI image, vendors aggregate updates for multiple CPU models and revisions into a microcode repository to ensure compatibility across supported processors.

Early SEC Phase Application

The initial loading sequence begins immediately after the processor executes its reset vector in the Security (SEC) phase:

  1. Reset Execution: The CPU starts executing instructions directly from SPI flash in a bare-metal state without access to physical RAM.
  2. Pre-Memory Requirements: Before main memory is initialized, the firmware uses the processor’s L3/L2 cache as temporary memory, a technique known as Cache-as-RAM (CAR) or No-Eviction Mode (NEM).
  3. BSP Patching: The Bootstrap Processor (BSP)—the primary core designated to lead initialization—must be stable enough to handle CAR. The SEC core searches the firmware storage for a microcode header matching the BSP’s CPUID and platform ID.
  4. Triggering the Update: The BSP writes the 64-bit physical memory address of the microcode payload into a designated MSR (for example, MSR 0x79 / IA32_BIOS_UPDT_TRIG on Intel platforms). The CPU hardware takes over, validates the internal checksum and digital signature, and loads the patch into its internal volatile execution units.

Multi-Processor Handling in the PEI Phase

Once the BSP finishes the initial SEC routine and initializes permanent system memory, the UEFI enters the Pre-EFI Initialization (PEI) phase. At this point, secondary cores—known as Application Processors (APs)—must also be updated:

  • Discovery via Modules: A dedicated PEI Module (PEIM), often named CpuMpPei or similar, initializes the multi-processor (MP) services protocol.
  • Waking the APs: The BSP sends Startup Inter-Processor Interrupts (SIPIs) across the local APIC bus to transition APs out of their halted Wait-for-SIPI state.
  • Per-Core Updating: Because microcode resides in volatile CPU-internal SRAM, every execution thread and physical core must independently trigger the update. The MP PEIM directs each AP to execute the update routine concurrently or sequentially, pointing to the same microcode buffer in memory.
  • Verification: Firmware reads the microcode revision register (such as MSR 0x8B on Intel after executing CPUID) on each logical core to confirm that the patch level matches the expected revision across all processors.

Transition to Subsequent Phases

By the time the UEFI transitions to the Driver Execution Environment (DXE) phase, all CPU cores are synchronized at the target microcode revision. This uniform execution environment prevents errata-induced crashes during PCI enumeration, ACPI table generation, and operating system loading. When the operating system eventually boots, its own kernel may re-check the microcode version and, if necessary, apply an even newer patch using an identical MSR-write mechanism to override the version supplied by the UEFI.