What CPU microcode actually does, and why old boards need updates

Every Intel desktop processor since the Pentium Pro carries a small program inside it that most owners never think about until a BIOS changelog mentions it. That program is microcode. It decides how some instructions are carried out, it can be patched after the chip leaves the factory, and the patch has to be loaded again every time the machine powers on. If you have put a server Xeon into a desktop board, the state of that patch matters before you go anywhere near a flash utility.

Microcode in plain terms

A processor's instruction set (x86, for everything on this site) is the list of commands software can give it: add these two numbers, copy this block of memory, compare and jump. The silicon does not run those commands directly. The front end of each core decodes every instruction into smaller internal steps called micro-operations, and the execution units work through those.

Simple instructions are decoded in hardware, fast. Awkward ones are handed to a microcode sequencer, which reads a stored routine of micro-operations from memory on the chip and feeds it into the core. The Core microarchitecture behind Core 2 and the 45 nm Xeons splits the work roughly like this:

So microcode is not the whole brain of the CPU. It implements complex instructions, rare special cases (Intel calls some of these assists) and a good deal of internal housekeeping.

Why it can be patched at all

Early x86 chips kept their microcode in fixed ROM. If a routine was wrong, the chip was wrong. The original Pentium's 1994 FDIV division flaw, for example, ended in Intel replacing processors on request. Starting with the P6 design (the Pentium Pro, in the mid-1990s), Intel added a way to patch microcode from the BIOS or the operating system. The ROM stays as it is. An update fills a small block of on-chip SRAM with replacement micro-operations and programs a set of match registers that redirect the sequencer to the new routine whenever it reaches a patched address.

Three properties of that design explain most of the practical headaches:

1. The patch is volatile. It lives in SRAM, so it is gone at power off. Intel's README for its Linux package states that microcode state resets on a power reset, which is why something has to load the update on every single boot.
2. Each update targets one exact chip. An update carries the CPUID signature it was written for (family, model and stepping, where a stepping is a revision of the silicon such as C0 or E0) and a mask of platform IDs. A processor with a different signature rejects it. Updates are encrypted and checked by the processor itself, so in practice every usable update comes from Intel, directly or through a board or OS vendor.
3. Revisions only go up. Intel notes that its OS loading method cannot downgrade a chip to a lower revision, so whatever loads first sets the floor for anything loaded after it.

Errata, the reason updates exist

Intel publishes a specification update for each processor family, and much of it is a list of errata: places where the chip behaves differently from its own datasheet. Some get a workaround for BIOS or software writers, some are fixed in a later stepping, and some are fixed by a microcode revision, the only kind of fix that reaches a processor already sitting in your socket. Intel's README describes the symptoms those fixes target in plain words: hangs, crashes, unexpected reboots and data errors.

How an update reaches the CPU

A microcode update can come from two places: the firmware, before any operating system runs, or the operating system as it boots.

Firmware

The BIOS image carries a set of microcode patches, one for each CPUID and platform combination the board maker chose to support. At power on, the firmware looks for the entry that matches the installed processor and loads it before handing over to anything else. Part of what a "support for new processors" BIOS release adds is usually the microcode for those processors. Intel calls the BIOS the preferred route, and some updates are firmware-only and never appear in OS packages.

Linux

The kernel documentation describes early loading in detail. Your distribution packs Intel's microcode into an uncompressed cpio archive at the front of the initrd. During boot, before the other cores are started, the kernel finds the patch matching the CPU, applies it to the boot processor and then to every other core, and keeps a copy in memory so it can reapply it after the machine wakes from sleep. On Debian and Ubuntu the package is intel-microcode; on Arch it is intel-ucode.

The same page names one of the loader's purposes as "updating the microcode on platforms beyond the OEM End-Of-Life support." That is the old-hardware case in a single line.

Late loading, pushing an update into a running system, is riskier: the two threads of a Hyper-Threading core share one microcode engine, and an interrupt in the middle of an update can misbehave. Since kernel 5.19 it is off by default.

Windows

Windows does the same job with a system file, mcupdate_GenuineIntel.dll, and an AMD counterpart for AMD chips. Microsoft ships new versions of the file as separate updates; KB3064209 from June 2015, for example, replaced it on Windows 7 SP1 through Windows 8.1 to fix Intel CPU issues that could cause crashes. Those packages only arrive on versions of Windows that are still being serviced.

Reading the revision you have

The revision is a hexadecimal number. Higher means newer, but only between updates for the same CPUID.

On Linux, Intel's README suggests these two checks:

grep microcode /proc/cpuinfo | sort | uniq
dmesg | grep -i microcode

The first prints a line like microcode : 0xa0b (one per logical core, collapsed by uniq). The second shows what the kernel's microcode driver did at boot, including whether it applied an early update.

On Windows, HWiNFO lists the microcode update revision among the processor details. You also need the CPUID itself; our guide to finding the CPUID, stepping or sSpec covers the tools and the markings on the heat spreader.

A worked example

Say you have a Xeon E5450 or an E0-stepping Core 2 Quad Q9550. Both report CPUID 1067A: family 6, extended model 1 plus model 7 (so model 0x17), stepping 0xA. Intel's repository names microcode files by family, model and stepping in hex, so the file for this chip is 06-17-0a. The first 16 bytes of each file are a header, and the README shows how to read them:

$ od -t x4 06-17-0a | head -1
0000000 00000001 00000a0b 09282010 0001067a

Read left to right: header version 1, revision 0xa0b, date 09/28/2010 (month, day, year), and the signature 1067A. If /proc/cpuinfo shows 0xa0b, nothing newer exists in Intel's public package. If it shows something lower, the OS loader did not run or your distribution does not ship that file. The 65 nm parts look similar: the Kentsfield G0 file (06-0f-0b, CPUID 6FB) carries revision 0xba from October 2010. For practical purposes, Core 2 microcode stopped moving in late 2010.

Security changed what updates are for

For most of the Core 2 era, microcode updates were quiet bug fixes. That changed in January 2018 with Meltdown and Spectre, a group of attacks that abuse speculative execution. Mitigating Spectre variant 2 needed new controls inside the processor, and those could only arrive as microcode, through BIOS releases and operating system packages.

In April 2018 Intel published revised microcode guidance and stopped work on variant 2 updates for a list of older families: Bloomfield, Clarksfield, Gulftown, Harpertown, Jasper Forest, Penryn, SoFIA 3GR, Wolfdale and Yorkfield. Harpertown is the Xeon 5400 series; Wolfdale and Yorkfield are the 45 nm Core 2 Duo and Quad. The reasons Intel gave were microarchitectural characteristics that made a practical mitigation unworkable, limited software support, and customer input that most of these chips ran in closed systems. The guidance also noted that mitigations for variant 1 and Meltdown, handled in operating systems and compilers, were not affected.

Put plainly, a Q9550 or an E5450 will never get a variant 2 fix from Intel. A current operating system still applies its software mitigations, but the chip itself stays where its 2010 microcode left it.

Microcode fixes are not only about security, and they are not only for old chips. In 2024 Intel traced crashes on 13th and 14th generation Core desktop processors to what it called Vmin shift instability, where the minimum voltage a core needs to run stably creeps upward. Intel's September 2024 statement listed four causes and the matching mitigations: its Intel Default Settings guidance for board power limits, microcode 0x125 (June 2024) for an eTVB algorithm issue, 0x129 (August 2024) for high voltage requests, and 0x12B, which includes both and also stops high voltage requests at idle and light load. Owners received it as BIOS updates from their board makers. As The Register's coverage pointed out, an update stops the cause but does not undo damage already done; chips that had already degraded went back under warranty.

Why old boards stop getting them

Three supply lines dry up, roughly in this order:

• The board maker stops releasing BIOS updates. For LGA 775 boards that happened long ago, so the BIOS you have is very likely the last one, and its microcode may predate Intel's final revision.
• Intel stops producing microcode for the family. For Core 2 and Harpertown, the file dates above say 2010.
• The operating system stops shipping updates: Microsoft only services current Windows versions, and Linux distributions can only package what Intel releases.

The OS loader papers over the first gap well: it brings the CPU to the newest public revision on every boot. What it cannot do is help during POST, when the firmware has already run the processor with whatever patch the BIOS had, or none.

The LGA 771 Xeon case

The Xeon swap makes all of this concrete. An E5450 and an E0 Core 2 Quad Q9650 share CPUID 1067A, but the Xeon was built for a different socket and reports a different platform ID (a three-bit field Intel uses to tell package types apart). A desktop BIOS was built with patches for the platform IDs the board maker expected, and a server package was never on that list.

Install a modded Xeon and the firmware may find no matching entry. Owners commonly report a range of outcomes: an "unknown CPU" message, a normal-looking boot with the chip running unpatched, or random instability under load. The fix the modding community settled on is adding the Xeon's microcode entries to the BIOS image. Our LGA 771 Xeon microcode guide explains which CPUIDs and platform IDs matter for the mod and where official microcode comes from, and the Xeon E5450 page lists that chip's details.

Before you open a BIOS editor

Work through this in order and stop once the problem is solved:

1. Read the revision your CPU reports after boot, using the commands above.
2. Check the board maker's support page for a newer official BIOS. An official release beats a modified image every time.
3. On Linux, install your distribution's microcode package, rebuild the initrd if it does not happen automatically, reboot, and look for the early update in dmesg.
4. If the BIOS still lacks an entry for your processor and you need it present at POST, editing the image is the remaining route. The guides for AMI BIOS and Award or Phoenix BIOS walk through it, starting with a backup of the chip you already have.

If step 3 already shows revision 0xa0b on a 1067A chip, you are running the last microcode Intel ever published for it, and no BIOS edit will give you a newer one.

Sources and further reading

• Intel, Intel Processor Microcode Package for Linux (README: loading methods, signatures, platform IDs, reading the header)
• The Linux kernel documentation, The Linux Microcode Loader
• Microsoft Support, June 2015 Intel CPU microcode update for Windows (KB3064209)
• Wikipedia, Intel microcode (background on the P6 update facility and the Core decoders)
• Wikipedia, Pentium FDIV bug
• TechCrunch, Last march of the Penryns: Intel cuts Spectre fixes for some older chips (April 2018, quotes Intel's guidance)
• The Register, Intel rolls out 'final' microcode fix for Raptor Lake CPUs (September 2024, reproduces Intel's list of causes and mitigations)