smiiiiiiiiiiiiiiii: breaking the SMM all-cores rendezvous with one very long instruction

The assumption smiiiiiiiiiiiiiiii attacks

System Management Mode is the execution environment x86 firmware uses for power, thermal and platform work that the operating system is not allowed to see. Its security model rests on a synchronisation rule: at any instant, every core is either inside SMM or outside it. When one thread raises an SMI and enters SMM, the others are expected to follow. A core that stays outside while another is inside can observe and interfere with SMM state, which is exactly the situation the architecture tries to prevent. The project's premise is that this rule is enforced by a timeout rather than by hardware, and that a timeout can be missed. The README frames the whole thing as an exercise in being too busy to answer an interrupt: all you need is a core that cannot be pulled into SMM at the moment the invitation arrives. The audience is people who already read firmware source for fun, not application developers looking for a hardening library.

Why the delay has to be a single instruction

An SMI is taken at an instruction boundary. That detail decides the entire design. If the victim core is executing a loop of short operations, the pending SMI lands in one of the gaps between them and the core joins SMM like everyone else. So the stall cannot be a busy-wait loop of many cheap instructions, or a sleep, or anything the CPU can interrupt. It has to be one instruction that never retires for roughly a second. The README puts the target at around 4,000,000,000 cycles, which it describes as over a second of wall-clock time, against an `add` that takes one cycle. The number is not arbitrary: it comes from the firmware side. The README quotes the EDK II loop in `UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c` that runs when a core enters SMM, calling `StartSyncTimer` and `IsSyncTimerTimeout` until either all cores have arrived or one second has passed. That one-second ceiling is the window the attacker has to outlast, and the code has to do it while remaining a single uninterruptible operation.

The mechanism: a wide load from slow MMIO

The proof of concept does not invent a new instruction. It finds an address where reads are answered extremely slowly and then reads as many bytes from it as the ISA allows in one go. The README describes the recipe as locating a high-latency MMIO address, abusing an undocumented region that answers reads at a crawl, using the widest load available to move as many bytes as possible in a single instruction, and letting other cores contend for the same bus to slow it further. On the machine the PoC was tuned for, a Zen 3 Ryzen 7 5800H, the address is `0xfcc68860` and the instruction is a wide `xmm` load. The README gives the assembly directly: `mov $0xfcc68860, %rsi` followed by `vmovdqu (%rsi), %xmm0`. One core spins on that load and stays outside SMM. A second core arms per-core SMI counters through the AMD performance MSRs `MSR_PERF_CTL0` at `0xc0010200` and `MSR_PERF_CTR0` at `0xc0010201`, writing the event selector `0x43002b` and zeroing the paired 48-bit counter. The timing race is the whole exploit: the waiting core gives up, does its SMM work and exits, and only then does the stalled core arrive.

Building it and what the first run looks like

The repository is a Makefile, a single C file, a LICENSE and an `examples/` directory containing `smi.gif`. The Makefile is short and does not install anything system-wide. It compiles `smiiiiiiiiiiiiiiii.c` with `gcc`, `-O2 -Wall -mavx -march=native`, and produces a binary named `smiiiiiiiiiiiiiiii` in the repository root. Clone the repository, then build with make:

make

That single command is the whole build; there is no configure step and no install target. The resulting binary is `smiiiiiiiiiiiiiiii` in the repository root. To remove it again, the Makefile provides a clean target:

make clean

Running the binary is where the platform dependency bites. The README states the PoC is tuned for a Zen 3 Ryzen 7 5800H and names the MMIO address `0xfcc68860`, so on any other machine the first run is an experiment in whether the load stalls long enough, not a supported execution. The README does not document command-line flags for the binary, so there is nothing to configure before you run it.

Where the proof of concept stops being usable

The README is candid that the approach is platform-specific, and that is the honest way to read the repository. The address `0xfcc68860` and the choice of a wide `xmm` load are tuned for one part. On other silicon the undocumented slow region may not exist, may be at a different address, or may not stall for a full second, and the README does not provide a discovery procedure beyond the general recipe of finding a high-latency MMIO address. There is also no documented way to know in advance whether the load is long enough on your machine; the only signal is whether the race works. The failure mode is not a clean error. A core stuck in a long load while the machine tries to synchronise cores for firmware work is a hang, and the README offers no recovery path, no watchdog advice and no statement about which firmware versions or microcode revisions close the window. Treat it as a demonstration that the rendezvous can be missed, not as a test harness you can point at an arbitrary fleet.

How this differs from chipsec-style SMM testing

The usual way to look at SMM from the outside is a firmware analysis and testing framework such as Chipsec, which enumerates platform configuration, checks whether SMM protections like SMRR and the TSEG lock are enabled, and reports on firmware settings through a kernel driver and a Python interface. That approach asks whether the platform is configured correctly. This project asks a different question: whether the synchronisation itself can be defeated at runtime by controlling instruction latency. Chipsec gives you a repeatable check with output you can compare across machines. smiiiiiiiiiiiiiiii gives you a race that either fires or does not, on hardware it was tuned for. If your goal is an auditable answer about a fleet of laptops, the framework is the right instrument and this repository is not. If your goal is to understand the timing assumption underneath the rendezvous, the PoC is the more direct artifact, and the README's annotated timeline of one core waiting while the other is stuck is the clearest explanation of the window you are attacking.

Licence, maintenance and the cost of carrying this code

The repository is MIT licensed, which permits reuse, modification and redistribution provided the copyright notice and permission notice are included. That is permissive enough to lift the assembly snippet or the MSR constants into another project, but the licence says nothing about whether the technique is safe or legal to run on hardware you do not own. On maintenance: the repository is not archived, and the last push was on 2026-08-18, which is recent enough that the code has not been left to rot. There are no retrieved releases, so there is no versioned artifact to pin and no changelog to read before upgrading. Upgrading means pulling the branch and rebuilding, and because the PoC is tied to a specific CPU and a specific address, a pull can change behaviour on your machine without any version number to warn you. Budget for that: the real cost of depending on this code is the platform-specific retuning, not the build.

Editorial conclusion

Adopt this only if you already work on x86 firmware security and you have a machine you are willing to wedge: the README targets a Zen 3 Ryzen 7 5800H and the address 0xfcc68860, so on any other platform you are redoing the MMIO search yourself. If you need a general SMM testing method or a portable tool, this is the wrong repository, because the PoC is explicitly platform-specific and the README describes the timing window rather than a supported interface. Before running anything, verify that your CPU is the one the PoC was tuned for, that you can recover the machine after a hang, and that you understand the MSR writes the code performs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. xoreaxeaxeax/smiiiiiiiiiiiiiiii on GitHub