Glonce

A pathologically long CPU instruction can break x86 SMM's security guarantee

securityThe Glonce editorsHacker News🔥71Glonce rating71Impact75Novelty75Relevance70Surprise65Players40Credibility85
A pathologically long CPU instruction can break x86 SMM's security guarantee

System Management Mode (SMM) is x86's ultra-privileged execution environment, and its security model rests on one rule: when any core enters SMM, all cores enter together. Firmware enforces this with a rendezvous loop that waits for every core to arrive, or gives up after 1 second, whichever comes first. Security researcher Christopher Domas found that this timeout is itself the weak point: keep one core busy with a single instruction that runs longer than that 1-second window, and the firmware gives up waiting on it, lets the other cores proceed into SMM without it, and finishes SMM's secret work while that one core is still outside. Because an SMI can only interrupt a core between instructions, the trick has to be a single uninterruptible instruction, not a loop, and it has to run for around 4,000,000,000 cycles, over 1 second of wall-clock time. Domas found such an instruction by pointing a wide vector load at an undocumented, unusually slow memory-mapped I/O (MMIO) address; reading from it takes long enough on its own to blow past the rendezvous timeout. He packaged the technique as a public proof-of-concept tool called smiiiiiiiiiiiiiiii. Tuned for the specific test machine, a Zen 3 Ryzen 7 5800H, it stalls one core with a vmovdqu load from MMIO address 0xfcc68860 while a second thread arms AMD's per-core performance-counter MSRs (MSR_PERF_CTL0 at 0xc0010200, MSR_PERF_CTR0 at 0xc0010201) to count SMIs handled by each core, fires an SMI storm by writing to I/O port 0xb2, and then compares the counters: if they diverge, one core missed SMIs that the others serviced, meaning it ran unsynchronized while SMM was active elsewhere. The stakes go beyond a curiosity. SMM's guarantee that nothing else runs while it executes is what keeps a large class of known bugs, over 100 SMM time-of-check-to-time-of-use (TOCTOU) CVEs where a handler checks a value in shared memory and later uses it, from being exploitable: normally nothing can rewrite that value in between, because no core is running outside SMM to do it. The only prior route in was a DMA-capable peripheral writing to memory from outside the CPU entirely, which needs physical access to the machine, so the whole bug class has sat mostly unpatched as a hardware-only problem. Breaking the rendezvous removes that requirement: an unsynchronized core running ordinary software, no physical access or extra hardware needed, can now be the one rewriting the shared value mid-check, turning dormant CVEs into software-exploitable ones. Domas is candid that there is no obvious fix. Keep the 1-second timeout and the rendezvous stays breakable this way; remove it and a core that is legitimately stuck for any reason would hang the whole platform on the very first SMI; lengthen it and many-core systems, which must quiesce every core on every SMM entry, pay a real performance cost. His stated workaround for now is simply not to execute long instructions, which he treats as a stopgap rather than a resolution. The proof-of-concept's defaults only reproduce the divergence on that one Zen 3 Ryzen 7 5800H test machine; on any other system the README says to expect no divergence until the long instruction is retuned, using the author's mmiotic tool to find a slow MMIO region on the target platform, widening the load from xmm to ymm or zmm width until the stall clears the local SMM timeout, or, if no MMIO read is slow enough, substituting a different pathologically slow instruction from the author's separate asm-hall-of-shame collection.

Key facts

  • Christopher Domas released a proof-of-concept, smiiiiiiiiiiiiiiii, showing that a single x86 instruction lasting around 4,000,000,000 cycles (over 1 second) can make one core skip SMM entirely while the others enter it.
  • The trick exploits SMM firmware's own rendezvous loop, which waits for all cores to enter SMM or gives up after 1 second, whichever comes first.
  • The tuned proof-of-concept, built for a Zen 3 Ryzen 7 5800H, stalls a core with a vmovdqu load from MMIO address 0xfcc68860, then uses AMD MSRs 0xc0010200 and 0xc0010201 and an SMI storm triggered through I/O port 0xb2 to detect the desync via diverging per-core SMI counts.
  • Domas says over 100 known SMM TOCTOU CVEs previously required a DMA-capable peripheral with physical access to exploit; breaking the core rendezvous removes that requirement, making them exploitable from software alone.
  • No fix is settled: keeping the timeout leaves it breakable, removing it risks hanging the platform on a stuck core, and lengthening it costs performance on many-core systems; the current recommended workaround is simply avoiding long instructions.

Why it matters

SMM's entire security model depends on the assumption that nothing runs outside it while it is active. This proof-of-concept shows that assumption can be broken with nothing more than a single overlong instruction, no special hardware or physical access required. That turns a large class of previously dormant bugs, over 100 known SMM TOCTOU CVEs, from a hardware-access problem into one that is exploitable purely from software.

Who it affects

Anyone whose platform security depends on x86 SMM isolation: firmware and BIOS engineers, and researchers or vendors building on top of SMM's guarantees. The working demonstration is on an AMD Zen 3 Ryzen 7 5800H, using AMD-specific MSRs and SMI triggering, but the underlying weakness is in the SMM rendezvous mechanism itself rather than one chip.

How to use it

smiiiiiiiiiiiiiiii is a research tool, not a packaged attack: it builds with make and runs with sudo, firing the long instruction repeatedly while watching each core's SMI counter for divergence. Its defaults only reproduce the effect on the exact test machine; porting it means finding a slow MMIO region on the target platform with the author's mmiotic tool, widening the vector load from xmm to ymm or zmm until the stall outlasts the local SMM timeout, or swapping in a different long-running instruction from the author's asm-hall-of-shame if no MMIO read is slow enough.

How solid is it

The write-up includes full working assembly and C for the technique, the exact MSR addresses and I/O port used, and a stated single author, Christopher Domas (@xoreaxeaxeax). It does not give a publication date, does not say whether any CPU vendor has acknowledged or responded, gives no CVE identifiers for the 100+ TOCTOU issues it references, and does not claim any of them have actually been exploited in the wild by this method, only that the technique makes them exploitable.

Risks and caveats

There is no agreed fix. Domas lays out the tradeoff directly: keep the 1-second rendezvous timeout and it stays breakable this way; remove it and a core stuck for an unrelated reason hangs the whole platform on the first SMI; increase it and many-core systems pay a performance cost because they must quiesce every core on every SMM entry. His interim workaround, not executing long instructions, is explicitly a stopgap, and the technique as published is tuned to one specific machine rather than generalized across x86 platforms.

“SMM's security relies on a simple assumption: while it runs, nothing else does.”

— Christopher Domas, smiiiiiiiiiiiiiiii project write-up