Intel microcode

Lore & Background

Originally, Intel microcode was implemented as a fixed ROM within the CPU die. Since the P6 microarchitecture introduced in the mid-1990s, the microcode programs can be patched by the operating system or BIOS firmware to work around bugs found in the CPU after release. Intel had originally designed microcode updates for processor debugging under its design for testing (DFT) initiative. Following the Pentium FDIV bug, the patchable microcode function took on a wider purpose to allow in-field updating without needing to do a product recall.

In the P6 and later microarchitectures, x86 instructions are internally converted into simpler RISC-style micro-operations that are specific to a particular processor and stepping level. Starting with the Pentium Pro, in most Intel x86 processors, instructions are converted by the instruction fetch and decode unit to sequences of processor-specific micro-operations that are directly executed by the processor. For the instructions that are implemented in microcode, the microcode consists of micro-operations fetched from on-chip memory. On the Pentium Pro, each micro-operation is 72-bits wide; newer Intel P6-derived CPUs add some more bits, some of them are shared for all microoperations in a triad. Other sources say microoperations are 118-bits wide. This includes an opcode, two source fields, and one destination field, with the ability to hold a 32-bit immediate value. The Pentium Pro is able to detect parity errors in its internal microcode and report these via the Machine Check Architecture.

During development of the Pentium Pro, several microcode fixes were included between the A2 and B0 steppings. For the Pentium II, additional micro-operations were added to support the MMX instruction set. In several cases, 'microcode assists' were added to handle rare corner-cases in a reliable way. The Pentium 4 can have 126 micro-operations in flight at the same time. Micro-operations are decoded and stored in an Execution Trace Cache with 12,000 entries, to avoid repeated decoding of the same x86 instructions. Groups of six micro-operations are packed into a trace line. Complex instructions, such as string move, result in jumping to the microcode ROM. During development of the Pentium 4, microcode accounted for 14% of processor bugs versus 30% of processor bugs during development of the Pentium Pro.

Reader's Guide

The introduction of patchable microcode with the P6 microarchitecture marked a significant shift in processor reliability and lifecycle management. Originally conceived for debugging under Intel's design for testing initiative, the facility gained broader importance after the Pentium FDIV bug, enabling in-field updates without product recalls. This capability allowed Intel to address post-release bugs through operating system or BIOS firmware updates, reducing the need for costly hardware replacements. The microcode update mechanism uses a set of match registers that act as breakpoints within the microcode ROM, allowing jumps to updated micro-operations stored in SRAM. The update process requires protection ring zero access and is initiated via a wrmsr instruction. Each update is encrypted and validated by the processor, with specific encryption and signature verification schemes varying by generation—for example, Goldmont CPUs use RC4-drop512 decryption, SHA256 hashing, and RSA-2048 signature verification. The format of microcode updates has been fully reverse engineered for P6 and derived CPUs, though Intel keeps precise encryption details restricted to fewer than ten employees. The ability to patch microcode has become a standard feature across Intel x86 processors, influencing how processor bugs are managed and how security vulnerabilities can be mitigated after silicon has shipped.

Did You Know?

• The 8086 defines 512 words of microcode.
• Intel Goldmont CPUs decrypt microcode content with RC4-drop512, hash it with SHA256, and verify the signature with RSA-2048.