This document describes details about the microcode update (MCU) process on current Intel processors. We do not describe any future enhancements to the microcode update process — just information about recent processors. Linux* administrators can find more information on updating microcode from the OS in the Loading Microcode from the OS article.
Microcode Update Points
This section describes the points when a microcode update may be loaded, listed as they occur chronologically from boot time.
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.
- For products based on the Sandy Bridge and Ivy Bridge microarchitectures, a microcode update is loaded from the FIT only on the BSP core if Intel® Trusted Execution Technology (Intel® TXT) is enabled.
- For server products based on the Skylake microarchitecture (including Cascade Lake and Cooper Lake microarchitectures, except Xeon E3), a microcode update is loaded from the FIT on the BSP core only.
- For products based on the Haswell and Broadwell microarchitectures, client products based on the Skylake microarchitecture (including Xeon E3), Atom family products starting with the Goldmont microarchitecture, and all later microarchitectures, a microcode update is loaded from the FIT 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.
Where possible, Intel recommends loading new microcode updates from the FIT; for example, through installing a BIOS update.
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 are 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.
Guidelines for Microcode Updates
Behavior Expectation from Loading Microcode Updates
A given microcode update may contain multiple individual components. For example, one component is used to add the IA32_SPEC_CTRL MSR and its underlying capabilities, while another component is used to add MD_CLEAR functionality to the VERW instruction. Additional components may also be used to mitigate various errata. Microcode updates are generally cumulative, which means that each update is a superset of all preceding updates for a given Processor Signature (CPUID Family/Model/Stepping) and Platform ID.
Microcode updates may introduce new capabilities. New capabilities are designed to be introduced in ways that will not break existing software that may be unaware of the changes. Software changes may be required to take advantage of the new capabilities. An example of this is the IA32_SPEC_CTRL MSR, which was introduced to existing processors through a microcode update.
Loading a microcode update will generally not remove any existing capabilities that may cause already running software to misbehave. This applies to baseline CPU functionality as well as any capabilities added via previous microcode updates. Exceptions to this will generally be communicated.
The microcode update is generally cleared by a warm reset. However, any state that persists across a warm reset (for example, last branch records or machine check banks) and has been modified by the update will remain modified after the reset.
One exception is that certain microcode update components only take effect after a warm reset (and thus are not cleared by warm reset). For such components, loading the update stages certain changes to take effect on the next warm reset. Since a warm reset generally clears the microcode update content, the processor may be affected only by those components that take effect after a warm reset between when that reset occurs and when the microcode update is later reloaded (at one of the previously discussed locations for microcode updates). A second warm reset (after the update is reloaded) is not needed.
Some microcode update components may only be effective if the update is loaded at or before a specific load point. In particular, some components may not take effect if the update is loaded after the late BIOS microcode update, or outside of the FIT. Any such requirements will be documented. If any component is not effective, it does not prevent other components within the same update from being effective.
Some microcode update components may impact system performance. Since the microcode update load point may determine the effectiveness of certain components, the performance impact of those components may also depend on the load point. Therefore, the same microcode update may have a different performance impact depending on when it is loaded.
Loading an update on one logical processor also loads the same update on all other logical processors in the same core (all of the sibling hyperthreads). For some processors, loading an update on one logical processor may also load the same update on logical processors on other physical cores. This may differ based on different configurations.
If software attempts to load an update with the same update revision as what is currently loaded, the CPU may or may not reload the update. Software can check the revision of the currently loaded update by executing the CPUID instruction and reading IA32_BIOS_SIGN_ID (MSR 8BH) to avoid reloading the same update unnecessarily.
Once loaded, some updates may prevent loading of another update with a lower update revision. If loading an update with a lower revision is allowed, loading the lower revision may not clear all aspects of the previously loaded update with the higher revision.
Loading a microcode update that creates a new software-controllable state will initialize that state to a well-defined setting described in the documentation associated with that particular capability.
Loading a microcode update will not perturb any settings of previously configured software-controllable states (for example, MSR values), even if those states were created by a previously loaded microcode update.
Procedure for Runtime Microcode Update
To load an update during runtime, software should synchronize all logical processors within the system (perform a rendezvous) to load the update in a coordinated manner.
Once all logical processors have been synchronized, one logical processor in each core should load the update while sibling logical processors wait in a spin loop of only basic instructions. Some guidelines are:
- The spin loop should not contain MWAIT or HLT. PAUSE or LFENCE may be used to throttle the loop.
- Software may load microcode on each core in parallel.
- To help improve performance, software should check that the microcode is newer than what is already loaded immediately prior to doing the write. This may avoid redundant microcode updates, especially on processors where a microcode update also updates microcode on other cores.
- You can see an example of the microcode update procedure below:
microcode_update_sync() {
primary_thread_done = 0
check in to MCU_GO barrier
wait for MCU_GO barrier
if (primary_thread_of_core) { // always true if no HT
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id < 0 || update_id > rev_id) {
load_update()
}
primary_thread_done = 1
} else { // other HW threads (if they exist)
while (primary_thread_done == 0) {
pause //lfence is also acceptable
}
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id != rev_id &&
(update_id < 0 || update_id > rev_id)) {
load_update()
}
}
check in to MCU_DONE barrier
wait for MCU_DONE barrier
}
Note Executing the CPUID instruction will populate IA32_BIOS_SIGN_ID (MSR 8BH) with the current Update Revision regardless of the leaf value specified in EAX.
Debugging
If the microcode update fails to load, system administrators should consider the following:
- Check the microcode version from the EFI shell, or the BIOS screen.
- Check what version of microcode is included in the initramfs image.
- The version of the microcode update you used to try to do a runtime update.
- The microcode image is named after the family/model/stepping. You can locate these from /proc/cpuinfo. For example:
- Family 06, Model 85, Stepping 4 (values in decimal).
- The corresponding microcode file is 06-55-04 located in /lib/firmware/intel-ucode/2 (values in hexadecimal).
- Look at the microcode version number at the official public Intel microcode website. Calculate Family-Model-Stepping before downloading appropriate microcode.
Note that you can only update to a higher version of microcode. Currently loaded microcode version is shown in /proc/cpuinfo.
- Microcode version number is included in the binary header of each microcode file. To read it dump the first 16 bytes of the file. Refer to the following example:
$ od -t x4 06-55-04 0000000 00000001 02000065 09052019 00050654
Note In this example, 02000065 is the microcode version, 09052019 is the date on which the IPU was created, and 00050654 is the family/model/stepping in the format returned by the CPUID instruction.
- The Linux command $ dmesg | grep microcode or $ cat /proc/cpuinfo | grep microcode | sort | uniq will give you a microcode version for comparison. Alternately, you can look for a microcode revision in the BIOS.
- For BIOS update, if the microcode update fails to load, BIOS will revert to the original version of the microcode
- On Windows*, users can read the version with the following PowerShell command: reg query HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 /v "Update Revision".
- Or use the Intel® Processor Identification Utility tool to check the microcode version and compare against the latest microcode listed on Affected Processors: Transient Execution Attacks & Related Security Issues by CPU.
- More information: How to Find the Microcode Version Currently Running on your Processor.
References
- Intel® 64 and IA-32 Architectures Software Developer Manuals
- Vol. 3A, section 8.7.11 “Microcode Update Resources”
- Vol. 3A, section 9.11 “Microcode Update Facilities”
- Firmware Interface Table BIOS Specification
- Public Intel microcode website
Footnotes
- Components are explained more thoroughly in the Behavior expectation from loading microcode updates section.
- This is the default location where Linux* distributions install microcode.
Software Security Guidance Home | Advisory Guidance | Technical Documentation | Best Practices | Resources