Conjuring Hardware Failures to Breach CPU Privilege Boundaries

Conjuring Hardware Failures to Breach CPU Privilege Boundaries

Speaker: Christopher Domas

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

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

Reading time: ~9 minutes

Type: Briefing

TL;DR

Christopher Domas demonstrates MCEhammer, a novel exploitation technique that generates on-demand Machine Check Exceptions (MCEs) entirely from software, then uses them to interrupt AMD CPUs during System Management Mode (SMM) privilege transitions — achieving code execution at the deepest firmware privilege level. The attack exploits a design characteristic where AMD CPUs enter SMM with an unmodified Interrupt Descriptor Table, meaning an attacker who controls the IDT can redirect a machine check exception handler to malicious code executing with SMM privileges.

Introduction

Most security researchers treat ring zero — kernel-level execution — as the end of the road. Once you have the kernel, the game is over. Christopher Domas disagrees, and at Black Hat USA 2025 he showed why. Below the operating system and the kernel lies a layer that most defenders never think about: System Management Mode (SMM), the highest privilege level on x86 processors. Firmware code runs here, hypervisors cannot see into it, and its memory region (SMRAM) is locked away from everything else on the platform.

Domas's talk, "Conjuring Hardware Failures to Breach CPU Privilege Boundaries," reveals how a class of hardware events called Machine Check Exceptions — events the CPU fires when something goes catastrophically wrong with hardware — can be weaponized to interrupt code running inside SMM at precisely the right moment, turning a hardware anomaly into a privilege escalation primitive.

▶ Watch: Introduction and Machine Check Basics (00:00)

What Are Machine Check Exceptions — and Why They Matter

A Machine Check Exception (MCE) is the CPU's emergency signal for catastrophic hardware failures: memory corruption, cache errors, TLB failures, thermal events. Unlike normal interrupts, MCEs cannot be suppressed, masked, or deferred. Security-sensitive code that protects itself with every other interrupt-suppression mechanism — clearing the interrupt flag, the trap flag, DR7, NMI latching, SMI masking — is still vulnerable to an MCE.

The Linux kernel documents this clearly: MCEs "can be delivered at any time, even in a critical section where all normal interrupts are disabled. They must be handled immediately." The operating system's typical response is panic and shutdown, because the state of the machine after an MCE is unknown.

Domas identified this as an extraordinary exploitation primitive. If MCEs bypass all the defensive mechanisms that secure code relies on, then the ability to deliver an MCE at a chosen moment turns every protected execution environment into a potential target.

▶ Watch: Why Machine Checks Bypass All Defenses (06:00)

Building the Hammer: On-Demand MCE Generation from Software

The challenge is that MCEs are exceedingly rare in practice. On a healthy system, /proc/interrupts will show hundreds of events per second across every other interrupt category, but the MCE counter barely moves. Waiting for a natural MCE is not a viable exploit strategy.

Domas built a tool he calls the state disruptor to generate real, physical MCEs on demand, entirely from software. The approach exploits a characteristic of the northbridge — the chipset component managing memory and PCI communication.

The key insight came from reading data sheets: a "master abort" signal on the PCI bus (generated when one device tries to communicate with another that does not exist) could, under certain northbridge configurations, escalate into a machine check exception. Domas wrote a fuzzer that randomly flipped bits in 24 northbridge configuration registers via PCI config commands, then triggered a master abort to see if a machine check resulted. After several hours of fuzzing, the tool found three specific bit configurations that reliably escalated a master abort to an MCE — and could deliver that MCE from one CPU core to another.

The northbridge approach is just one of hundreds of possible MCE sources, and Domas notes the specifics vary substantially across CPU generations. But the pattern — find a configurable hardware path to an MCE, fuzz it, exploit it — is broadly applicable.

▶ Watch: Fuzzing the Northbridge for MCE Generation (12:00)

Targeting SMM: The IDTR Design Characteristic

With a reliable MCE generator in hand, Domas needed a target worth hitting. System Management Mode was the obvious choice. SMM is more privileged than ring zero — the OS cannot see SMRAM, hypervisors cannot reach it, and firmware uses it to store secrets, manage power states, and handle security-critical operations. A persistent implant at the SMM level survives OS reinstalls and drive wipes.

When the CPU enters SMM, it resets most of its register state to a known safe configuration. Examining AMD's architectural specification, Domas found one register conspicuously absent from the reset list: IDTR, the pointer to the Interrupt Descriptor Table (IDT). The IDT tells the CPU how to dispatch interrupts — which handler to call for a page fault, a debug exception, or a machine check (exception vector 18).

On AMD processors, the IDT is left unmodified when entering SMM. This means that if an attacker has already established kernel-level access and installed a malicious IDT entry for the machine check vector (entry 18), then a machine check exception that fires while the CPU is inside SMM will look up the attacker's IDT, jump to the attacker's handler, and execute that code with full SMM privileges.

AMD characterized this behavior as a design feature rather than a vulnerability. Domas characterizes it as "fragile by design" — it works correctly only if every piece of privileged code is bug-free in every edge case.

▶ Watch: The IDTR Register and SMM Entry (22:01)

The Attack Window: Threading the Needle

The attack requires one more ingredient: timing. SMM is designed so all CPU threads enter and exit together — a property called thread quiescing. When an SMI fires, all threads receive the signal and wait to finish their current instruction before entering SMM. This means an attacker cannot simply sit outside SMM and throw MCEs at a victim thread inside it, because all threads would be in SMM simultaneously.

Domas identified a narrow window: threads do not technically enter SMM at the same moment. Each finishes its current instruction first. This creates an attack window of approximately 100 cycles during which one thread can be inside SMM while another is still outside. The attacker must deliver the MCE within that window.

The MCE itself, generated through the northbridge master abort path, takes approximately 700 cycles for a standard PCI MMIO access — far too fast for the required delay. Domas's solution was to violate x86 memory access specifications deliberately. The architecture specifies that MMIO accesses must use EAX/AX/AL and must be naturally aligned to a DWORD boundary. Violating these requirements produces undefined behavior — and in practice, dramatically extends access times.

By misaligning an MMIO access by a single byte, Domas achieved access times of over 12,000 cycles. Calibrating the victim thread's delay alongside this extended instruction gave the attacker a mechanism to deliver the MCE within the 100-cycle attack window with precision.

▶ Watch: Timing the Attack — The Fuse Instruction (28:01)

MCEhammer: Full Chain Demonstration

The complete exploit chain, packaged as the MCEhammer tool, proceeds as follows:

1. Install malicious IDTs — The attacker (already at ring zero) installs a malicious interrupt handler for MCE vector 18 in the IDT.
2. Configure the northbridge — Specific bits are set to escalate master aborts to machine checks, and to route them cross-core.
3. Arm the time-fuse instruction — The attacking thread begins a deliberately misaligned MMIO access that will generate a master abort after approximately 10,000–12,000 cycles.
4. Trigger the SMI — The victim thread writes to I/O port B2, causing an SMI that pulls both threads toward SMM entry.
5. Race to the window — As the victim thread enters SMM and eventually re-enables MCE handling (via a mov CR4 instruction inside the UEFI firmware code), the time-fuse fires. The northbridge delivers the MCE to the victim thread.
6. Code execution in SMM — The CPU, now inside SMM on the victim thread, looks up the malicious IDT and jumps to the attacker's handler, which runs with full SMM privileges.

In the live demo, Domas dropped a command-and-control payload into SMM, gaining access to SMM secrets, the S3 resume state, and platform security processor (PSP) doorbell registers that no other code can reach.

▶ Watch: Full Exploit Chain and Demo (32:02)

Mitigations and Future Directions

Domas submitted a patch to EDKII (the open-source UEFI firmware reference implementation) to reload the IDT earlier during SMM entry, before MCE handling is re-enabled. This patch addresses the machine check delivery path but does not resolve the underlying IDTR design characteristic — the IDT still enters SMM in an untrusted state.

The machine check generation technique was developed and tested on pre-Zen AMD CPUs, using one specific MCE source out of hundreds of possible northbridge configurations. Future work could include:

• Row hammer bit flips in DRAM to generate DRAM-sourced MCEs
• ECC memory scrubbers generating asynchronous events
• Userland MCE generation via ring-three processor errata (which would re-open all the other vulnerable code paths that currently rely on interrupt suppression for protection)
• Extending the technique to hypervisors, secure guests, enclaves, and secure loaders
• Investigating similar hardware error event mechanisms on ARM, RISC-V, MIPS, and POWER architectures

As of the talk, the issue was not fully patched, and Domas indicated he would release technical details incrementally as fixes became available.

▶ Watch: Mitigations and Future Research (38:03)

Notable Quotes

"Machine check exceptions can be delivered at any time, even in a critical section where all normal interrupts are disabled. They must be handled immediately. There's no way out. We must die." — Christopher Domas, quoting the Linux MCE handler documentation ▶ 08:00

"A lot of people think once you get to ring zero on a system, the game's over. You've got everything you need. But it turns out on modern platforms, things actually get much, much deeper than that." — Christopher Domas ▶ 18:00

"We've got this state disruptor tool that lets us do on-demand generation of hardware machine checks entirely from software. I think this has never been done before." — Christopher Domas ▶ 18:00

"The vendor really didn't want to call this a vulnerability. So we're just going to call this a feature instead, and then we'll talk about how to exploit this feature." — Christopher Domas ▶ 24:01

Key Takeaways

• MCEs bypass all interrupt suppression. Any code that relies on masking interrupts for security — including SMM, SGX enclaves, and hypervisor transitions — is potentially vulnerable to a precisely timed machine check.
• On-demand MCE generation is now possible from software. The northbridge fuzzing technique produces real, hardware-level MCEs without requiring physical hardware manipulation or kernel simulation tricks.
• AMD's IDTR behavior during SMM entry is an architectural risk. Leaving the IDT unmodified when entering SMM means an attacker with ring-zero access can redirect MCE handlers to execute arbitrary code at the SMM privilege level.
• The 100-cycle attack window can be hit reliably. Deliberately violating x86 MMIO alignment specifications creates a time-fuse with sufficient delay and precision to target SMM entry.
• Patch EDKII to reload the IDT early in SMM entry. Firmware developers should apply the submitted EDKII patch, and review all MCE handling paths in SMM code.

Slides PDF: Not available at time of publication.