FIT Microcode Update
The Firmware Interface Table (FIT) is a data structure located in the platform BIOS SPI flash that may contain pointers to one or more microcode updates. Loading a microcode update from the FIT is the preferred way to load a microcode update in Intel platforms, because it helps ensure all the update components1 are loaded at the earliest point in the boot process. Before executing the first instruction of the BIOS firmware at the Intel® architecture (IA) reset vector, the CPU processes the FIT to locate a microcode update suitable for that particular CPU. If a suitable update is found, the CPU loads the update before the first instruction of the BIOS firmware is fetched. After loading an update from the FIT, the bootstrap processor (BSP) begins fetching and executing the BIOS firmware from the IA reset vector, while the application processors (APs) enter into the Wait-for-SIPI state.
On some processors, a microcode update is loaded from the FIT only on the BSP core, while on other processors, it may be loaded on all cores.
A microcode update is loaded from the FIT after either a warm or cold hardware reset. It does not occur in response to an INIT event. It is BIOS’s responsibility to ensure the validity and the integrity of the microcode update before incorporating it into the IFWI in flash memory.
Early BIOS Microcode Update
Early BIOS microcode update is when a microcode update is loaded by BIOS before memory has been initialized.
Early BIOS microcode update may be performed by early BIOS initialization on the BSP. BIOS may skip this microcode update if an update has already been loaded via the FIT. BIOS can determine whether an update was loaded from the FIT by executing the CPUID instruction and then reading IA32_BIOS_SIGN_ID (MSR 8BH). If IA32_BIOS_SIGN_ID[63:32] is non-zero, then an update was already loaded from the FIT, and the early BIOS microcode update load point may be skipped.
Intel recommends that updates are loaded very early in the BIOS initialization sequence, either via the FIT (preferred), or via early BIOS microcode update load before the BIOS Memory Reference Code is executed and before DRAM is available. This is needed to address issues that may affect the later BIOS code (like the BIOS Memory Reference Code).
When a microcode update is loaded from the FIT, it may be loaded on all processors or only on the BSP. When an update is loaded during early BIOS, it may also be loaded only on the BSP core, since application processor (AP) cores may not be awake at this point in the boot sequence. Therefore, as soon as possible after receiving the Startup Inter-Processor Interrupt (SIPI), BIOS software on the AP cores should load the update if it has not already been loaded from the FIT.
Late BIOS Microcode Update
On more recent processors, certain architectural features, such as Intel® Software Guard Extensions (Intel® SGX), require an additional late BIOS microcode update. In order to enable these architectural features, a late BIOS microcode update must be performed on all logical processors, even if the same microcode update has already been loaded from the FIT or during early BIOS. In that case, late BIOS must reload the same update that was loaded earlier. Failure to perform the late BIOS microcode update on all logical processors may prevent these architectural features from being used.
During a late BIOS microcode update, the update may perform certain checks on the memory configuration and/or other settings required to enable these features. To facilitate the system checks, late BIOS load must occur after all of the following are completed:
- DRAM and memory map is configured
- Invocation of the first System Management Interrupt (SMI)
- System Management Mode (SMM) handler relocation
- Processor Reserved Memory Range Registers (PRMRR) are configured
In a multisocket system, BIOS software must provide synchronization to perform the late BIOS microcode update on all sockets in parallel. During the update sequence, each CPU will attempt to synchronize with CPUs in other sockets. Failure to load the update in parallel across sockets may cause this synchronization to fail, which may prevent certain architectural features from being enabled. This multisocket synchronization is only necessary during the late BIOS microcode update on processors supporting features that specifically require it. It is not required when loading a microcode update from the OS.
Early OS Microcode Update
The operating system (OS) should check if it has a more recent microcode update (higher update revision) than the version applied by the BIOS. If it does, the OS should load that microcode update shortly after BIOS hands off control to the OS. This microcode update load point is called the early OS microcode update. This can be done by an early boot software layer such as a Unified Extensible Firmware Interface (UEFI) driver, a bootloader, the operating system, or any other software layer provided by the operating system (like early startup scripts). The early OS microcode update should be done on each core as early as possible in the OS boot sequence, before any CPUID feature flags or other enumeration values are cached by the OS software. It is also required to be loaded before any user-space applications or virtual machines are launched. This is necessary so that the update is loaded before the affected microcode is ever used, enabling any relevant mitigations for potential vulnerabilities as early as possible.
If the BIOS does not load the most recent microcode update, Intel recommends loading that update during the early OS microcode update.
Runtime Microcode Update
Runtime microcode update refers to loading an update while the system is fully operational and running workloads, possibly including user-space applications and virtual machines. Software should ensure that the same update is loaded on all cores. Some microcode updates may introduce new features and may change CPUID feature flags or other enumeration. Software that wishes to use features introduced via a runtime microcode update may need to reevaluate any CPUID feature flags or other enumeration after the update is loaded in order to take advantage of any new capabilities introduced by that microcode update.
Runtime microcode update should be used when a system reset would be problematic (for example, when a system reset would impact server uptime requirements). Where possible, it is preferable to load microcode updates through BIOS or early OS.
Top comments (0)