One Slow Instruction Breaks SMM's Core Guarantee

System Management Mode is the part of your x86 machine you're not supposed to think about. It sits below the operating system, below the hypervisor, below ring 0 — a sliver of firmware that the CPU drops into when it fields a System Management Interrupt (SMI), running code out of a memory region (SMRAM) that even a kernel can't read. Power management, fan curves, ECC scrubbing, TPM glue, and a lot of vendor cruft live there. Its entire security model rests on one physical invariant: when an SMI fires, every core stops what it's doing and enters SMM together. Nothing else runs. That's the guarantee.

Christopher Domas — the researcher behind sandsifter and a long line of x86 spelunking — just broke it with a single instruction.

The trick is that SMIs land on instruction boundaries

The rendezvous isn't magic. When firmware wants all cores in SMM, it broadcasts an SMI and then waits — on the tested platform, up to one second — for the stragglers to check in. A core enters SMM at the next instruction boundary. That's the seam. If you can keep a core inside a single machine instruction for longer than the rendezvous timeout, the SMI never gets a boundary to interrupt, the core never enters SMM, and the firmware eventually gives up waiting.

You need one instruction that runs for over a second. That sounds impossible until you remember memory-mapped I/O. Domas's proof-of-concept, tuned for a Zen 3 Ryzen 7 5800H, is a vector load from a deliberately glacial MMIO address:

vmovdqu (%rsi), %xmm0    ; rsi = 0xfcc68860, a very slow MMIO region

One load, aimed at the right device register, stalls the core for roughly four billion cycles. During that window, the other cores dutifully enter SMM while this one sits outside it, fully awake and executing attacker-controlled code. The invariant — all in or all out — is gone.

Why one desynchronized core matters so much

On its own, a stalled core is a curiosity. The payload is what it unlocks. There are well over a hundred known SMM TOCTOU (time-of-check-to-time-of-use) bugs sitting in shipped firmware, many with CVEs, most unpatched. The pattern is always the same: an SMM handler reads an attacker-influenceable value out of shared memory, validates it, then trusts it. Classic double-fetch territory — a pointer that's bounds-checked and then dereferenced, a length that's validated and then used for a copy.

These bugs have been treated as roughly unexploitable, and the reasoning was sound. To win the race you'd need something modifying shared memory while SMM runs, and thanks to the rendezvous, no CPU core is available to do it. The only remaining path was a DMA-capable peripheral scribbling behind the CPU's back — which means physical access or a malicious device. So the entire class got mentally filed under "hardware attack, not our problem."

SMI desynchronization deletes that prerequisite. A single core outside SMM, running ordinary software, can now flip the value between the check and the use. No device, no DMA, no bench access. The whole dormant class becomes live.

Read the severity carefully

This is not a remote exploit, and it isn't a break out of a browser tab. Poking raw MMIO addresses is a ring-0 operation; you already need kernel-level control to line this up. What Domas has built is a privilege-escalation primitive — a bridge from ring 0 into SMM, the one boundary that's supposed to hold even against a fully compromised kernel.

That's exactly why it's significant. SMM is where firmware rootkits want to live: persistent across OS reinstalls, invisible to the kernel, capable of tampering with the boot chain and Secure Boot state. The industry's answer to "what if the kernel is owned?" has partly been "SMM still isn't." This chips at that answer. It converts a large backlog of bugs that vendors could safely deprioritize into ones an attacker with kernel access can chain toward the most privileged code on the machine. Commenters floated USB or PCIe device emulation as a way to reach the necessary MMIO timing from a less privileged position — plausible, but for now theoretical.

There's no clean patch, and that's the interesting part

The obvious fix is to make the rendezvous unforgiving, and it doesn't work. The timeout exists for a reason: it has to be longer than the longest legitimate I/O operation on the platform, or a core genuinely stuck mid-transaction hangs the whole system on the first SMI. Shorten it and you risk faulting real workloads; lengthen it and you punish every SMM entry on high-core-count parts that already pay a quiescence tax. As one observer put it, you either hang the platform on a legitimately stuck core or you kill performance forcing dozens of cores to rendezvous on every SMI. The timeout is a genuine architectural pressure point, not a config someone forgot to harden.

Which pushes the real remedy down into the handlers themselves — where it arguably always belonged. SMM code cannot treat shared memory as stable. The discipline is the same one that kills double-fetch bugs everywhere: copy attacker-reachable inputs into SMRAM first, then validate the copy, then operate only on the copy. Never dereference a pointer you re-read from outside. Never check a length in one place and use it from another. Firmware written to EDK II conventions has the primitives to do this; the problem is the mountain of existing handlers that assumed atomicity they never actually had.

What to do with this

If you write or audit firmware, the assumption "nothing else runs while my SMI handler runs" is now false, and every SMM handler that reads shared memory more than once is a candidate. Grep your SMI dispatch for double-fetch patterns and marshal inputs into SMRAM before you touch them. If you build platforms, the CVEs you triaged as "requires physical access" need re-scoring — the DMA prerequisite is gone. And if you do offensive research, this is a reusable primitive: the specific slow-MMIO address is board-dependent, but the technique ports to any platform where you can find an instruction that outlasts the rendezvous.

The elegant, uncomfortable part is that nothing here is a bug in the usual sense. No overflow, no missing check. Domas just noticed that "all cores enter SMM together" was a promise the hardware couldn't actually keep — and that a decade of firmware was built on believing it.