Microcode sits in the gap between hardware and software. It’s the firmware layer underneath everything else, below the OS and below the BIOS, that turns the electrons-and-gates physics of a CPU into the x86_64 instructions you actually write code against. Almost nobody thinks about it, which is exactly why it’s worth knowing.
1. How microcode works#
Microcode is, roughly, an interpreter.
CISC is too complex to wire directly#
Modern x86 CPUs are CISC (Complex Instruction Set Computer). Instructions like REP MOVSB are not simple operations. One opcode triggers a whole routine: loops, memory reads, memory writes, counter updates. Wiring a dedicated physical circuit for every x86 instruction would be impossibly expensive.
The RISC core underneath#
Underneath, an Intel or AMD chip is closer to a RISC (Reduced Instruction Set Computer) machine. It speaks in micro-ops: load, store, add, branch. Microcode lives in the instruction decoder. When the CPU sees REP MOVSB, the microcode sequencer fetches a routine from internal ROM and emits a stream of those simple micro-ops.
The whole CISC ISA is, in a sense, a software emulation layer running on a RISC engine.
2. Updates are not persistent#
Microcode updates do not survive a power cycle. Modern CPUs keep the patched microcode in a small block of SRAM. SRAM is volatile. Cut power, lose the patch.
So how does the patch keep getting applied?
- Hard reset. The CPU loads base microcode from ROM fused into the silicon. This is the version that shipped.
- BIOS/UEFI. The motherboard firmware ships with its own microcode blob and pushes it to the CPU during init via an MSR write.
- Operating system. Windows and Linux both carry their own microcode payload, often newer than the BIOS one. Early in boot, the OS reapplies its version on top of the BIOS version.
This matters for red teaming. Downgrade the OS or sabotage the microcode loader and you can re-expose vulnerabilities like Spectre, Meltdown, or Downfall on a box that everyone thinks is patched. The silicon never changed; the patch was just RAM.
3. Signatures, integrity, and red unlock#
If microcode controls the CPU, what stops someone from uploading a malicious blob and turning the chip into a backdoor?
Cryptography, mostly.
The integrity check#
The public research consensus on Intel: the update blob is RC4-drop512 encrypted, the decrypted content is hashed with SHA-256, and the hash is verified against an RSA-2048 signature. The CPU stores a hash of the vendor’s public key in hardware fuses.
You load an update on Intel by writing the linear address of the buffer to MSR 0x79 (IA32_BIOS_UPDT_TRIG). The CPU does the verification and applies the patch only on success. Forging the signature would require breaking RSA-2048.
Side doors#
Researchers have gotten around this without forging signatures. The Red Unlock work by Goryachy, Ermolov, and Sklyarov (2020) exploited a chipset/CSME debug-mode vulnerability on Intel Goldmont (Apollo Lake / Gemini Lake atom-class chips) to activate an undocumented internal debug state. That state let them extract the microcode decryption key and dump the internal CPU ROM. Follow-on work like CustomProcessingUnit (Borrello et al., WOOT ‘23) used Intel’s own match-register debug interface to actually modify execution.
What you get on a chip where it works:
- The ability to read decrypted microcode and reverse-engineer Intel’s internals.
- The ability to plant custom microcode that persists until the next power cycle (the same SRAM volatility that bites the legitimate update path bites you here too).
- A path into things sitting behind microcode-enforced boundaries, including SGX.
It’s not a general-purpose exploit primitive. The bypass is bound to Goldmont-class chips with specific debug paths, usually needs vendor-debug or physical access, and doesn’t translate to current production silicon. But it’s the proof that “signed by Intel” only protects you from one of several attack surfaces.
4. Hardware security features lean on microcode#
Microcode doesn’t just decode instructions. It’s where a lot of the security boundaries are actually enforced.
Intel SGX#
SGX (Software Guard Extensions) is meant to keep enclave memory unreadable even to the kernel and hypervisor. That guarantee is enforced by microcode-mediated checks on every memory access into an enclave. Attacks like LVI (Load Value Injection) and SGAxe didn’t break the crypto — they found side channels in the microarchitectural logic underneath SGX and leaked secrets that way.
AMD SEV#
AMD’s Secure Encrypted Virtualization works similarly: the firmware running on the Platform Security Processor (PSP) and the main-CPU microcode together handle the encryption keys for VM memory.
In both cases, breaking microcode means breaking the security feature it’s supposed to enforce.
5. Microarchitectural attacks#
Most of the high-profile CPU bugs since 2018 target the microarchitecture rather than the architecture: caches, prefetchers, branch predictors, and execution-unit buffers. Things that exist purely to make the chip faster and are invisible to the ISA.
Speculative execution (Spectre / Meltdown)#
The CPU guesses what you’re going to do next and starts executing it before it knows whether the guess was right.
- The flaw. When the guess is wrong, the CPU rolls back the architectural state (registers, visible memory) but leaves traces in the microarchitectural state (cache contents). A patient attacker can measure cache timings and reconstruct what was speculatively executed, including data they shouldn’t have been able to read.
- The fix. Microcode updates added new fences like
IBPB(Indirect Branch Prediction Barrier) so software can tell the CPU “stop guessing across this boundary.”
Downfall (CVE-2022-40982)#
Targets 6th-through-11th gen Intel Core (Skylake through Tiger Lake). Abuses the GATHER instruction’s internal buffer to leak data across processes and out of SGX enclaves. Intel’s fix is a microcode update (Gather Data Sampling mitigation) that effectively disables the optimization, with up to 50% overhead on Gather-heavy AVX workloads.
Zenbleed (CVE-2023-20593)#
AMD Zen 2 only, but ugly. An unprivileged user can siphon data from other processes, other VMs, or the kernel at roughly 30 KB/s per core. That’s fast enough to grab keys, passwords, and session tokens in real time as they flow through registers. The bug is in how Zen 2 rolls back a mispredicted vzeroupper: the “z-bit” in the register allocation table for YMM registers doesn’t get properly restored, leaving stale upper-half data readable through later vector reads. AMD’s mitigation is a microcode update (and a chicken-bit workaround on kernels that need to patch around it until microcode is loaded).
6. Checking the version#
If you’re targeting one of these vulnerabilities, the patch level on the box tells you whether your PoC is going to work.
Linux#
# Current microcode revision
grep "microcode" /proc/cpuinfo | head -n 1
# What the kernel thinks about vulnerabilities and mitigations
grep . /sys/devices/system/cpu/vulnerabilities/*Windows (PowerShell)#
# Revision is in hex, e.g. 0xBA = 186
reg query "HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0" /v "Update Revision"Cross-reference against the vendor’s published microcode revision list to figure out which CVEs the box is still exposed to.
Closing#
Most security people treat microcode as a black box, including the ones who really shouldn’t. SGX, SEV, the speculative-execution mitigations, the branch-prediction barriers — they’re all enforced down here. And when something breaks at this layer, it doesn’t break like a kernel bug. The fix is a new microcode revision (or a new chip), and whatever fix you’ve got is living in volatile SRAM until the next power blip wipes it.
