[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-94483":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":17,"rankGlobal":9,"rankLanguage":9,"license":18,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":19,"hasPages":19,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":15,"starSnapshotCount":15,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},94483,"smiiiiiiiiiiiiiiii","xoreaxeaxeax\u002Fsmiiiiiiiiiiiiiiii","xoreaxeaxeax","A very very very very very very very long interrupt",null,"C",242,9,106,1,0,117,53,"MIT License",false,"main",[],"2026-08-24 04:01:22","# smiiiiiiiiiiiiiiii\n\nExploiting System Management Mode with a very very very very very very very long\ninterrupt.\n\n## Overview\n\nIt turns out that you can break SMM — the secure, ultra privileged execution\nenvironment running invisibly in the background of every x86 CPU — with nothing\nmore than an obscenely long-running machine instruction.\n\nSMM requires that all cores are either in SMM or out of SMM at the same time.\nIts security model doesn't work without this - when one thread enters SMM, it\nmakes all the others enter too.\n\nTo break this, all we need is someone too busy to notice they're supposed to\njoin SMM.\n\nIt works something like this:\n\n```\ncore 0 - start a long instruction\n       |\n       |\n       |\ncore 1 - invite core 0 to smm\n       |\n       |\n       |\ncore 1 - enter smm\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - wait for core 0\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\n       |\ncore 1 - give up\ncore 1 - do secret smm stuff\ncore 1 - finish smm\n       |\n       |\n       |\ncore 0 - join smm\n```\n\nAt this point, core 1 is out of SMM while core 0 is in, letting core 1 attack\ncore 0.  Here's the catch: for this to work we need a very, very, verrrrry long\ninstruction — longer than any instruction was ever supposed to take.  Most\nmachine instructions on a modern CPU are fast: `add` takes 1 cycle.  To get core\n1 to give up waiting on core 0, we need an instruction on core 0 that takes\naround 4,000,000,000 cycles — over 1 second of wall-clock time.\n\n## The One-Second Timeout\n\nx86 firmware runs the [following\ncode](https:\u002F\u002Fgithub.com\u002Ftianocore\u002Fedk2\u002Fblob\u002Fa70c8729668f30de067f4b9db2e69baba283856e\u002FUefiCpuPkg\u002FPiSmmCpuDxeSmm\u002FMpService.c)\nwhen a CPU core enters SMM:\n\n```c\n  for (Timer = StartSyncTimer ();\n       !IsSyncTimerTimeout (Timer, mTimeoutTicker) && SyncNeeded;\n       )\n  {\n    mSmmMpSyncData->AllApArrivedWithException = AllCpusInSmmExceptBlockedDisabled ();\n    if (mSmmMpSyncData->AllApArrivedWithException) {\n      break;\n    }\n\n    CpuPause ();\n  }\n```\n\nThe code waits for all cores to enter SMM, or for up to 1 second, whichever\noccurs first.  To get a core to execute SMM code while another core stays\nexecuting *outside* SMM, we need that outside core to stay uninterruptible for\nthe *entire* second — an SMI is taken at an instruction boundary, so any gap\nbetween two instructions lets the pending SMI pull the core into SMM.  The\ndelay therefore has to be a *single* instruction: one uninterruptible op that\noutlasts the one-second rendezvous.\n\n## Proof-of-Concept\n\nThere are many ways to reach the forbidden 1-second instruction, and the exact\napproach will vary platform-to-platform.  But, roughly: find a high-latency MMIO\naddress, and then convince the CPU to read from it as slowly as possible — abuse\nan undocumented region that answers reads at a crawl, use the widest load the\nISA will give you to move as many bytes as possible across it in a single\ninstruction, and let the other cores contend for the same bus to slow it\nfurther.  One read, one instruction, and the CPU is stuck holding it for the\nbetter part of a second.\n\nThe provided [proof-of-concept](.\u002Fsmiiiiiiiiiiiiiiii.c)\nis tuned for a Zen 3 Ryzen 7\n5800H, where a wide `xmm` load from slow MMIO at\n`0xfcc68860` stalls long enough to break the all-cores rendezvous:\n\n```asm\nmov     $0xfcc68860, %rsi   ; the target MMIO address\nvmovdqu (%rsi), %xmm0       ; the very, very long load\n```\n\nThe PoC exploits this by pitting two cores against each other.  One core is held\n*outside* SMM by the long instruction — a tight loop on the very slow load:\n\n```c\n\u002F* the victim core: spin on the ~1-second load, too busy to answer the SMI *\u002F\nfor (;;)\n    asm volatile (\"vmovdqu (%0), %%xmm0\" :: \"r\"(mmio) : \"xmm0\");\n```\n\nMeanwhile another core arms the per-core SMI counters:\n\n```c\n#define MSR_PERF_CTL0  0xc0010200        \u002F* AMD core perf event-select MSR *\u002F\n#define MSR_PERF_CTR0  0xc0010201        \u002F* the paired 48-bit counter      *\u002F\n\nfor (int cpu = 0; cpu \u003C ACTIVE_CPUS; cpu++) {\n    msr_write(cpu, MSR_PERF_CTL0, 0x43002b);  \u002F* EN | OS | USR | event 0x2b *\u002F\n    msr_write(cpu, MSR_PERF_CTR0, 0);         \u002F* zero the count            *\u002F\n}\n```\n\nThen fires a storm of SMIs:\n\n```c\nasm volatile (\"outb %%al, $0xb2\" :: \"a\"(0));  \u002F* kick port 0xb2 -> #SMI    *\u002F\n```\n\nAnd reads every core's tally back:\n\n```c\n\u002F* ...fire the storm, then read every core's tally back... *\u002F\nuint64_t delta = smi_max - smi_min;\nif (delta)\n    puts(\"!!! a core ran outside SMM\");\n```\n\nIf the counts diverge, it means a core kept running *outside* SMM while the\nothers were pulled in — it missed the SMIs the rest of them serviced.\n\nTo better illustrate this, we can run the proof-of-concept behind a needlessly\nflashy and entirely pointless GUI, tracking SMI counters on each core, to watch\nthem execute in perfect lockstep until a wildly delayed core breaks their\nrequired synchronization:\n\n![SMI counter divergence in action](examples\u002Fsmi.gif)\n\nSMM's one guarantee — that nothing else runs while it does — falls apart under a\nsingle absurdly long instruction.\n\n## Exploitation\n\nSMM's security relies on a simple assumption: while it runs, nothing else does.  \n\n[There](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2021-33164) [are](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-30773) [100+](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-34398) [SMM](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-21198) [TOCTOU](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-32471) [CVEs](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-30283) [out](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-43777) [there](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2021-42055): [an](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-30774) [SMM](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-26859) [handler](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-32469) [checks](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-43778) [a](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-32470) [value](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2023-28075) [in](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-32478)\n[shared](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2024-42444) [memory](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-33905), [then](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2024-42446) [uses](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2022-33985) [it](https:\u002F\u002Fwww.cve.org\u002FCVERecord?id=CVE-2023-22612).  All you need for exploitation is to rewrite \nthat value in between the check and use, and you're inside SMM.  But these\nissues sit *dormant* and largely unpatched in the wild, because of one\nassumption: exploitation requires something to modify the shared memory *while\nSMM executes*, and because of the SMM rendezvous no CPU cores are outside SMM to\nlaunch an attack.  The only way in was a DMA-capable peripheral writing behind\nthe CPU's back — physical access, a malicious device — so the whole class is\nwritten off as a hardware problem.\n\nSMI desynchronization removes the prerequisite that kept the platform safe: an\noutside core, no physical access or hardware required, can now run while SMM\nexecutes — and the dormant CVEs become exploitable from software.\n\n## Mitigations\n\nThere probably aren't any, which is what makes this one somewhat more\ninteresting than traditional SMM issues.  Keep the timeout, and the rendezvous is\neasily broken.  Remove the timeout, and a legitimately stuck core hangs the\nplatform on the first SMI.  Increase the timeout, and you kill performance on\nmany-core platforms that are forced to quiesce all cores every SMM entry.  It's\nnot clear what the best path forward is, or if there is even a path forward at\nall.\n\nUntil then, the recommended workaround is to not execute any long instructions.\n\n## Porting to your platform\n\nThe default `vmovdqu` at `0xfcc68860` in the proof-of-concept is a slow spot on\n*this* box — a Zen 3 Ryzen 7 5800H — and likely nowhere else.  To break the\nrendezvous on *your* box, you will need to retune the long instruction so the\nstall outlasts *your* SMM timeout.  Some tips on how to do this:\n\n1. **Aim at your MMIO.** Find a slow MMIO region on your platform with\n   [mmiotic](https:\u002F\u002Fgithub.com\u002Fxoreaxeaxeax\u002Fmmiotic).\n2. **Widen the read.** Step `-r xmm → ymm → zmm` until the stall crosses the\n   rendezvous timeout.\n3. **Swap the instruction.** If no single MMIO read is slow enough, you need a\ndifferent pathologically long instruction; the\n[asm-hall-of-shame](https:\u002F\u002Fgithub.com\u002Fxoreaxeaxeax\u002Fasm-hall-of-shame) shows how\nto find them.\n\n## Building\n\n```sh\nmake          # builds smiiiiiiiiiiiiiiii\n```\n\n## Usage\n\n**The defaults are tuned to one machine.** On anything but a Zen 3 Ryzen 7\n5800H, expect no divergence until you retune the long instruction — see\n[Porting to your platform](#porting-to-your-platform).\n\nRun the tool to repeatedly fire the very-very-long instruction while watching\neach core's SMI counter for a divergence:\n\n```sh\nsudo .\u002Fsmiiiiiiiiiiiiiiii          # default: -r xmm at 0xfcc68860\n```\n\n**Flags:**\n\n| Flag | Default | Description |\n|------|---------|-------------|\n| `-r xmm\\|ymm\\|zmm` | `xmm` | Vector register width for the timed MMIO read (16\u002F32\u002F64 bytes). If no SMI count delta is observed, the tool advises stepping up to the next size. |\n| `-a \u003Cphys-addr>` | `0xfcc68860` | Target physical address for the MMIO timing loop (hex `0x...` or decimal). |\n| `-h`, `--help` | — | Print usage and exit. |\n\n## References\n\n* [DEF CON 2026 – Weaponizing Uselessness](https:\u002F\u002Fmedia.defcon.org\u002FDEF%20CON%2034\u002FDEF%20CON%2034%20presentations\u002FDEF%20CON%2034%20presentations\u002FDEF%20CON%2034%20-%20Christopher%20Domas%20-%20Weaponizing%20Uselessness%20Breaking%20SMM%20with%20the%20Slowest%20Instruction%20Ever%20Written%20-%202026.pdf)\n\n## Author\n\n`smiiiiiiiiiiiiiiii` is a research effort from Christopher Domas ([@xoreaxeaxeax](https:\u002F\u002Fx.com\u002Fxoreaxeaxeax)).\n","这是一个利用x86架构系统管理模式（SMM）同步机制缺陷实现的漏洞概念验证工具，通过执行超长运行的机器指令（如rep stosb）阻塞单个CPU核心响应SMM进入请求，从而破坏多核间SMM状态一致性，导致SMM隔离失效。项目基于纯C语言实现，不依赖外部库，聚焦于底层硬件行为触发与验证。适用于操作系统安全研究、固件安全审计及SMM相关漏洞教学演示等场景，需在可控实验环境（如QEMU\u002FKVM或物理测试机）中运行。",2,"2026-08-10 02:30:05","CREATED_QUERY"]