Entrysign: Create Your Own x86 Microcode for Fun and Profit

EntrySign: Create Your Own x86 Microcode for Fun and Profit

Speakers: Eduardo Vela Nava (Google), Josh Eads (Google), Kristoffer "spq" Janke (Google), Matteo Rizzo (Google)

Conference: OffensiveCon 2025 — May 16-17, 2025, Berlin

YouTube: https://www.youtube.com/watch?v=sUFDKTaCQEk

Reading time: ~10 minutes

TL;DR

A Google security team discovered EntrySign, a cryptographic flaw in AMD's microcode patch signing scheme affecting every AMD CPU from Zen 1 through Zen 5: the signature algorithm uses AES-128 CMAC with a hardcoded key, a construction whose compression function is invertible, allowing attackers with root access to forge a valid signature over arbitrary microcode. Combined with a separate Platform Security Processor (PSP) vulnerability on Zen 1 that enabled extraction of the signing key, the researchers demonstrated end-to-end arbitrary microcode execution on AMD hardware — breaking the trust boundary underlying AMD's Confidential Computing (SEV) platform.

Introduction

CPU microcode is the firmware layer beneath x86 machine code: a RISC-like micro-operation language that implements complex x86 instructions and can be updated at runtime to patch hardware bugs. Since Intel introduced runtime-patchable microcode following the infamous Pentium FDIV bug in the 1990s, both Intel and AMD have signed microcode updates to prevent unauthorized modification. Root access is required to load a patch, but the assumption has been that the cryptographic signature prevents a root-level attacker from actually changing what the CPU executes.

EntrySign shatters that assumption for all AMD Zen-generation CPUs. The Google team — Eduardo Vela Nava, Josh Eads, Kristoffer Janke, and Matteo Rizzo, along with Tavi (not present) — spent 2024 working through a complete reverse engineering of AMD's microcode format, signing infrastructure, and internal micro-op ISA. The result is a publicly released tool called Zento that can sign and load arbitrary microcode on any AMD Zen CPU, enabling modifications ranging from changing instruction semantics to breaking AMD's Confidential Computing trust model.

x86 Microcode: What It Is and Why It Matters

▶ Watch: Microcode fundamentals and motivation (0:00)

Modern AMD Zen CPUs implement a three-stage model: fetch x86 bytes from memory, decode them, then execute. Simple instructions (moves, adds) take a "fast path" requiring only a few micro-ops fixed in logic. Complex instructions are microcoded: the decode stage recognizes them, looks up their address in a Microcode Sequencing ROM (MS ROM), and executes a sequence of micro-ops from there. The microcode RAM (a small internal SRAM) can override ROM entries to apply runtime patches.

Loading a microcode patch requires root access. This has led some to dismiss the security relevance of microcode exploitation, but the researchers identify three classes of features that are explicitly designed not to trust root:

1. RTM (Rely on Trusted Microcode): Reinitializes the CPU core to a trusted state; the foundation for Windows Hello, Microsoft Intune, and System Guard. A forged microcode patch can subvert this measurement.
2. AMD SEV (Secure Encrypted Virtualization / Confidential Compute): AMD's Trust Computing Base (TCB) includes only AMD hardware and firmware. Microcode is part of that TCB. A compromised microcode patch can break tenant-VM isolation from a malicious hypervisor or cloud provider.
3. Security research: Arbitrary microcode execution enables binary diffing of AMD patches (which historically ship with no changelog), adding features like hardware conditional breakpoints, and analyzing how AMD actually fixed a given hardware bug.

Reverse Engineering the Microcode Update Format

▶ Watch: Microcode update acquisition and format analysis (8:00)

The team sourced microcode updates from a crowdsourced open-source repository that aggregates BIOS firmware extracts from community contributors. Examining several hundred AMD updates spanning 2020–2022, they noticed an anomaly: a significant portion of Zen-generation updates were not encrypted, apparently due to a process bug in AMD's build pipeline. This unencrypted sample set provided the plaintext necessary to understand the format without first breaking the encryption.

Each microcode update binary consists of:

• Metadata: patch application information including the target CPU family, model, and stepping.
• Match registers (hook-and-replace): pairs of ROM addresses and replacement microcode addresses, redirecting execution when the CPU fetches a microcoded instruction at a matched address.
• Mask values: a mechanism for converting non-microcoded (fast-path) instructions into microcoded instructions — useful for patching simple instructions that are ordinarily handled in hardware without a ROM lookup.
• Patch contents: sequences of quads — groups of four RISC-like micro-ops each paired with a 32-bit sequence word that controls microcode engine flow (jump to patch RAM, return to ROM, branch delay handling).

The micro-op ISA traces its lineage to AMD's NextGen/RISC86 and K6 architectures. Each micro-op carries a top-level class code; control flow is governed by sequence words and micro-op jump instructions such as JNZ.

Tracing the Compilation Pipeline with IBS

▶ Watch: IBS tracing technique (14:00+)

AMD's Instruction-Based Sampling (IBS) is an architectural performance monitoring feature that, when configured via the IBS_OP_CTRL MSR, fires an interrupt after a programmable number of micro-ops retire and records per-µop telemetry: memory access type, size, virtual and physical addresses, or ALU results when no memory is accessed. The team weaponized IBS as a microcode execution tracer.

By configuring IBS to sample every N-th micro-op and replaying a microcode update load millions of times, they reconstructed a trace of more than one million micro-ops covering the update validation routine. The trace revealed the CMAC computation in detail — 16-byte sequential loads on the public key and 11 AES round-key constants were the telltale pattern — and identified the encryption scheme on Zen 2+ updates as XXTEA (eXtended Tiny Encryption Algorithm) based on the characteristic load-4/store-4 pattern of that algorithm's round function.

With the encryption scheme and key identified from the trace, the team decrypted previously opaque updates and extended their plaintext sample set to later CPU generations.

The EntrySign Cryptographic Flaw

▶ Watch: Signature forgery technique (18:00+)

AMD signs microcode updates with RSA (2048-bit key, public exponent 65537, PKCS#1 v1.5 padding). The update binary contains three 256-byte blocks: a signature block, a public key (or public key hash) block, and an additional data block. The structure that AMD signs is not the raw microcode content — it is an AES-128 CMAC over that content.

The fatal flaw: CMAC is a message authentication code, not a hash function. CMAC's compression function is based on AES encryption:

This function is invertible: given the AES key and the output state, one can recover the input by computing AES_Decrypt(key, state_n) XOR state_{n-1}. The researchers confirmed that AMD hard-coded the AES-128 key inside the CPU silicon. For Zen 1 through Zen 4, the key is literally the example key from the AES-CMAC RFC. Zen 5 uses a different key but the same structural vulnerability.

CMAC forgery exploits invertibility as follows:

1. Compute the CMAC forward over the desired payload to obtain an intermediate hash state.
2. Run the CMAC computation backward from AMD's known-good target hash value to generate one 16-byte "garbage" prefix block that, when prepended to the payload, produces a CMAC collision with AMD's signature.

This forged CMAC, combined with the RSA signature from a legitimately signed AMD update (which covers that same CMAC value), produces a fully valid signature over attacker-controlled microcode content.

The team extracted the AES key by leveraging a separate PSP vulnerability: a 2018-era AMD PSP (Platform Security Processor) flaw in Zen 1 (originally disclosed by CTS-Labs as "Master Key") allowed loading a crafted firmware module that exposed a memory-copy service. By taking a CPU core offline via kernel hotplug, overwriting the core's CC6 sleep area (a DRAM region where the CPU saves register state during power-gating) with a custom microcode patch via the PSP, and then bringing the core back online, they achieved arbitrary microcode execution on Zen 1. A two-instruction microcode gadget then loaded the AES key register value into an IBS-traceable load address, leaking the key value through the IBS trace.

AMD's fix, deployed in a microcode update, replaces CMAC with a Merkle-Damgård construction over a Matyas-Meyer-Oseas compression function using a block cipher with state-dependent chaining keys — a scheme that is not invertible.

Live Demo: Backdooring RDRAND

▶ Watch: Live demonstration (40:00+)

The team demonstrated EntrySign live on a Zen 1 system running AMD microcode version 0x8001129. Using the Zento tool (released publicly on GitHub), they:

1. Printed the existing microcode to confirm the target version.
2. Created a custom patch that hooks the RDRAND instruction (hardware random number generation) to always return the value 4 — a nod to the classic XKCD "chosen by fair dice roll" joke.
3. Attempted to load the unsigned patch — rejected, as expected.
4. Ran zento resign to apply the CMAC forgery, generating a signature that passes AMD's verification.
5. Loaded the resigned patch — accepted; the microcode version counter incremented.
6. Verified that RDRAND on CPU 0 now returns 4 on every call, while other CPUs remain unaffected.

The patch hides itself by configuring the match register with two NOP instructions to disguise the hook. Patches are cleared on reboot.

Notable Quotes

"From the architecture of AMD, the microcode is part of the trust boundary. So if you can execute your own microcode, you can break Confidential Compute." — Eduardo Vela Nava, ▶ (8:00)

"We started looking through the unencrypted updates and realized most of the AMD microcode updates had not been encrypted from around 2020 to 2022. It seemed like they had some bug in the process. And this was a huge revelation for us." — Josh Eads, ▶ (10:00)

"The AES key for Zen 1 through Zen 4 is literally the example key from the AES-CMAC RFC. That is the key they used." — Kristoffer Janke, ▶ (18:00+)

Key Takeaways

• EntrySign exploits the invertibility of AES-128 CMAC — used as AMD's microcode signature hash — to forge valid RSA signatures over arbitrary microcode on all AMD Zen 1 through Zen 5 CPUs; the attack requires root access.
• AMD's signing key was the AES-CMAC RFC example key for Zen 1–Zen 4, making key discovery trivial once the algorithm was identified; Zen 5 uses a different key but the same flawed construction.
• IBS (Instruction-Based Sampling) serves as a powerful black-box microcode tracer: by sampling micro-op telemetry over millions of update-load replays, the team reverse-engineered the CMAC computation, identified XXTEA encryption on Zen 2+ updates, and ultimately leaked the signing key.
• AMD's Confidential Computing (SEV) trust boundary is broken on unpatched systems: microcode is explicitly in AMD's TCB, and arbitrary microcode execution allows a hypervisor-level attacker to undermine tenant VM isolation.
• AMD's fix replaces the invertible CMAC construction with a Merkle-Damgård scheme using Matyas-Meyer-Oseas compression, which cannot be run backward; the Zento toolchain is publicly available for researchers to continue reverse engineering AMD microcode updates.