Assembly Hall of Shameとは｜最遅x86命令を競うリーダーボードとSMM前提が壊れる話

Assembly Hall of Shame（xoreaxeaxeax/asm-hall-of-shame）は、x86の単一命令を「どれだけ速く」ではなく「どれだけ遅く」実行できるかを競う、風変わりなリーダーボードです。作者は sandsifter（x86プロセッサファザー）や movfuscator（単一命令Cコンパイラ）で知られるリバースエンジニア Christopher Domas 氏。2026年8月6日の公開後すぐにHacker Newsで421ポイントを集め、確認時点で654スターに達しています。

一見すると命令オタクの遊びですが、読み進めると2つの明確なセキュリティ境界に触れます。1つは、普通のコードから漏れ出て無関係な他コアまで巻き込む split lock。もう1つは、1秒を超える1命令がSMM（System Management Mode）の「全コア同期」という前提を崩す話です。この記事では、収録された命令を実測値で整理し、なぜ遅いのか、そしてどこがセキュリティに接続するのかを一次ソースで確認します。

低レイヤの命令が引き起こすクロスコアDoSやSMM経由の権限昇格は、突き詰めれば「信頼できないコードが同じ物理マシンを共有する」というマルチテナント／サプライチェーンの問題に接続します。その全体像はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストで扱っています。本記事はその最下層＝CPU命令のレベルで何が起きるかを見ていきます。

タイムライン（すべて確認済みの一次情報）：

・2020年8月（Linux 5.8）：split_lock_detect がカーネルに追加。split lock/bus lockを検出・緩和できるようになる（既定は warn）
・2021〜2024年：SMMハンドラのTOCTOU系CVEが多数公表（CVE-2021-33164・CVE-2022-30773ほか100件超）。ただし「SMM実行中は外にコアがいない」ため休眠状態とされてきた
・2026年8月6日：asm-hall-of-shame と姉妹プロジェクト smiiiiiiiiiiiiiiii が同日GitHubに公開（両リポジトリの作成日）
・2026年8月7日：Hacker Newsに投稿され421ポイント・110コメント（公表日）
・2026年8月10日（本記事の確認時点）：asm-hall-of-shame は654スター。補助ツールの一部（rakefield等）は未公開（404）

Assembly Hall of Shameとは——「最速」ではなく「最遅」を競うリーダーボード

Assembly Hall of Shame の面白さは、視点をひっくり返したところにあります。命令レイテンシの解析は普通「この命令をいかに速く回すか（最適化）」を問いますが、このプロジェクトは逆に「単一命令のレイテンシの床はどこまで下げられるか（＝最遅）」を問います。READMEの冒頭にある通り、目的は “the absolute floor of single-instruction performance” を探すことです。

ルールは明快で、そのままセキュリティ的にも意味を持ちます。

・採点対象は1命令だけ。セットアップに何命令使ってもよいが、点になるのはただ1つの命令
・トラップ／エミュレート／仮想化される命令は、トラップまでしか計測できない（ハンドラの時間は数えない）
・割り込み可能な命令は失格。rep movs や pause は不可。つまり採点対象は「途中で止められない、割り込みが差し込めない1命令」に限られる
・時間はCPUのベースクロックで正規化する
・すべて工場出荷時の構成で計測。ハードウェア改造は禁止

3番目のルール「割り込み不可能な単一命令」は、後半のSMMの話で決定的に効いてきます。SMI（System Management Interrupt）は命令の境界でしか入れないため、1つの割り込み不可能な命令が長ければ長いほど、SMIが差し込めない時間が延びるからです。遊びのルールが、そのまま攻撃の前提条件になっているわけです。

作者の Christopher Domas 氏（@xoreaxeaxeax）は、x86の隠し命令を総当たりで探す sandsifter（5,000スター超）、実在するx86チップのハードウェアバックドアを暴いた rosenbridge、mov 命令だけでCコードをコンパイルする movfuscator（1万スター超）などで知られます。「x86の底を突く」系の仕事を長く続けてきた人物で、本プロジェクトもその系譜にあります。

27命令のリーダーボード：1 cycleから1,980億cyclesまで

リーダーボードは27命令が並び、最下位（＝最速）の nop（1 cycle）から最上位（＝最遅）の fxrstor64 変種（約1,980億cycles）まで、11桁の開きがあります。対数目盛りで見ると、遅さがどこで跳ね上がるかがよく分かります。

代表的な命令を、遅さの度合いとともにいくつか拾ってみます。

・nop（1 cycle）：何もしない命令。リーダーボードの基準点
・idiv（77 cycles）：128ビット被除数に小さな除数を与え、除算器マイクロコードの最長経路を通す
・clflush（165 cycles）：ダーティなキャッシュラインをフラッシュ
・fsin（257 cycles）：指数部を特殊値にしてx87マイクロコードの「特殊値処理」へ落とす
・split lock（865 cycles）：lock 命令のオペランドをキャッシュライン境界にまたがせ、外部バスロックを踏ませる（後述）
・cpuid（1,248 cycles）：作者ツール rakefield で最も高レイテンシなCPUIDリーフを探索して当てる
・wbinvd（約162万 cycles）：全キャッシュ階層をDRAMへ書き戻して無効化。ring 0が必要
・in（約1,250万 cycles）：ACPI PMブロックと思しきI/Oポートへの非整列4バイト読み。複数の非ポスト転送へ分解される
・mov（約4.4億 cycles）：mmiotic でPCIeファブリックの「高レイテンシな死角」を探し、不明なGPUレジスタを読む
・fxrstor64（約1,980億 cycles・62秒）：512バイトのFPU/MMX/XMM状態を極端に遅いMMIO領域から読み、さらに他コア群で同じファブリックを飽和させて待たせる

チャンピオン fxrstor64 の戦略は象徴的です。この命令は512バイトの状態イメージを一括ロードしますが、そのロード元をPCIeファブリックの遅いMMIO領域に置くと、512バイトすべてがファブリックを渡り切るまで命令が退役（retire）できません。さらに「ハンマーコア」群が別の高レイテンシMMIOレジスタを4バイト読みで叩き続け、ルートコンプレックスを非ポストトランザクションで飽和させることで、CPU 0の fxrstor64 はその渋滞の後ろに並ばされます。結果が62秒。単一命令の実行に、です。

なぜ遅いのか——遅延を生む4つの層

27命令をひとつずつ暗記する必要はありません。遅さは概ね4つの層のどこで詰まるかで決まります。下の層ほどCPU内部で完結し、上の層ほどCPUの外まで往復します。

L1：通常のパイプライン内で完結（1〜112 cycles） nop・rdtsc・idiv・enter などは、いくら手を尽くしてもCPUコアのパイプライン内で完結します。idiv は128ビット被除数×小さい除数で除算器の最長経路を、enter は最大ネスト深度31で30回のディスプレイポインタ処理を通す——それでも100 cycles強にとどまります。ここは「命令の素の重さ」の世界です。

L2：マイクロコード・アシストへの脱線（数百 cycles） FPUの非正規化数（subnormal）が典型です。x87の実行ユニットは正規化数の高速経路を前提に作られており、非正規化数を食わせると命令を完了できず、長いマイクロコード列（PMUの FP_ASSIST.ALL が発火）へ落ちます。fadd（677 cycles）・fdiv（883 cycles）はこの脱線を狙ったものです。興味深いことに、READMEは「Skylake以降のSSE/AVXスカラは非正規化を高速化したが、x87には同じ手当てがなくマイクロコードの重さが残る」と指摘しています。古い命令ほど遅くしやすい、という非対称です。

L3：外部バスロック・全キャッシュ書き戻し（数千〜百万 cycles） ここから「1コアの中だけでは済まない」世界に入ります。split lock（865 cycles）は外部バスに #LOCK を張り、wbinvd（約162万 cycles）は全キャッシュ階層をDRAMへ書き戻します。rdmsr（約16万 cycles）は、VIAの未文書化MSR（0x133）という「読むと異様に時間がかかる」レジスタを当てています。作者いわく「何をしているのか分からない」。

L4：CPUの外＝MMIO/PCIeファブリック越え（数億〜数千億 cycles） 最上位の層はすべてMMIOがらみです。mov・vmovdqu・fxrstor64 はいずれも、PCIeファブリック上の「反応が異常に遅い死角（多くはGPUの未文書レジスタ）」へアクセスします。読むバイト数が増えるほど遅くなるので、mov（4バイト）→ vmovdqu xmm（16バイト）→ vmovdqu ymm（32バイト）→ fxrstor64（512バイト）と、命令の転送幅がそのままスコアに効きます。ここでの遅延は、もはや命令の重さではなく「バスの向こう側がどれだけ遅く応答するか」で決まります。

リーダーボードに載っていない6命令——Assembly Hall of Shameのソースを読む

ここで一次ソースを実際に読むと、READMEの27命令リーダーボードには載っていないのに、ディレクトリにはスコア付きのREADMEが存在する命令が6件見つかります。リポジトリのディレクトリ一覧とリーダーボードを突き合わせると、fyl2x rdseed split_lock_hammer vmovdqu32_zmm vpgatherdd lock_hammer_mmio の6つが「計測済みだが未掲載」でした。

とくに lock_hammer_mmio は約137億 cycles（3.188秒）で、掲載されていれば現在の3位（vmovdqu ymm (unaligned) の約44.5億 cycles）を上回り、堂々の上位に食い込みます。中身を読むと、これはL3とL4の合わせ技です。MMIOアドレスに lock 接頭辞つきの read-modify-write を投げると、キャッシュラインが存在しない（UC領域なので）ため真のバスロックにフォールバックし、しかも全論理CPUが同じMMIOアドレスへ同時にバスロックを投げると、各ロック取得が他の全ロックのファブリック往復完了を待つ——という直列化が積み上がります。

これは「READMEの完成度」の話に見えて、実は本サイトの読者に効く教訓を含みます。リーダーボード（要約）だけを見て分かった気になると、ソースにある一番過激な事例を取りこぼす、ということです。公開直後のリポジトリは、トップのREADMEとサブディレクトリの実測が同期していないことがよくあります。数字を引用するなら、要約ではなく実体（各命令のREADMEとCソース）を当たるのが安全です。

split lock——普通のコードから漏れる「遅い命令」の危険

ここまでの命令の多くは、MMIOアドレスの探索や特権命令（ring 0）を必要とする「意図して作らないと出てこない」ものでした。ところが split lock は違います。特別なセットアップなしに、普通のアプリケーションコードから漏れ出てくる——そこが危険です。

仕組みはこうです。lock 接頭辞つきの命令（lock xadd・lock inc など）は、通常はMESIキャッシュコヒーレンス経路を使います。発行コアが対象キャッシュラインをM状態で獲得し、read-modify-writeを行って解放する——他のハードウェアは巻き込まれません。ところがオペランドがキャッシュライン境界をまたぐと、単一ラインの所有権では両側をカバーできず、CPUは外部バスに #LOCK を張る「split lock」へフォールバックします。read-modify-writeの全区間で、他のどのコア・どのソケットもバストランザクションを発行できなくなります。

問題は3点あります。

・引き金がアドレス整列だけ：命令そのものは高速パスと同一で、境界をまたいでいるかどうかの違いしかありません。キャッシュライン境界に張り付いた構造体や、整列指定なしに確保されたミューテックスが、静かにsplit lockを生みます。コードレビューでは見えません
・無関係な他コアまで減速：多くの直列化命令は自コアだけを遅くしますが、split lockはバスを保持する間、何も悪いことをしていない他プロセスまで巻き込みます。READMEは「10〜30倍遅くなり得る」と記します。これはマルチテナント環境におけるクロスコアDoSの原始要素です
・検出はできるが既定は「警告」：Linux 5.8以降は split_lock_detect で検出できます。ただし一次ソース（カーネル文書）を確認すると、既定は warn（警告して継続、直列化で並行実行を抑制）であり、プロセスを SIGBUS で殺すのは split_lock_detect=fatal を明示的に設定したときだけです。Assembly Hall of Shame のREADMEは「既定でSIGBUSを送る」と書いていますが、これは正確ではありません。既定は警告であり、致命化はオプトインです

この「既定は警告」という差は運用上重要です。何もしなければ、悪意あるプロセスが延々とsplit lockを撒いても、システムは警告を出しつつ動き続けます（並行実行の抑制で速度は落ちます）。リアルタイム性や近隣テナントの性能を守りたいなら、ratelimit:N や fatal の採用を検討する必要があります。

影響範囲：split lockが「クロスコアの性能干渉」として問題になるのは、①lock 接頭辞つきのアトミック命令を含み、②整列指定なしにキャッシュライン境界をまたぐデータ構造が生じ得て、③信頼できないコードと物理コアを共有する（マルチテナント／共有ホスト／リアルタイム混在）——この3条件がそろう環境です。検出フラグ split_lock_detect を提供するのはIntelのTremont/Icelake世代以降などに限られ、AMDや古いIntelでは検出できません（発生しないという意味ではありません）。SMM側の影響範囲は、SMMランデブーの1秒タイムアウトに依存する一般的なx86ファームウェア全般で、ファームウェア更新でしか根本対処できない点が回避不能条件です。

最遅命令がSMMの前提を壊す——smiiiiiiiiiiiiiiiiとセキュリティの接続

ここが Assembly Hall of Shame の最も鋭いセキュリティ接続点です。作者は同じ日に姉妹プロジェクト smiiiiiiiiiiiiiiii（「とても長い割り込み」の意）を公開し、最遅命令のテクニックでSMMの安全前提を崩せることを示しました。冒頭のGIFはそのライブ監視画面です。

SMM（System Management Mode）は、すべてのx86 CPUの裏で不可視に動く、極めて高い特権を持つ実行環境です。そのセキュリティモデルは、たった一つの前提に依存しています——「あるスレッドがSMMに入ると、他の全スレッドも同時にSMMに入る」。実行中はSMMの外に誰もいない、という同期（ランデブー）が成立して初めて、SMMは安全に振る舞えます。

このランデブーには時間制限があります。一次ソースであるTianoCore EDK2のファームウェアコード（PiSmmCpuDxeSmm/MpService.c）を読むと、SMMに入ったコアは「全コアがSMMに入る」か「最大1秒経過する」かのどちらかまで待ちます。

// TianoCore EDK2: PiSmmCpuDxeSmm/MpService.c（抜粋・一次ソース）
for (Timer = StartSyncTimer ();
     !IsSyncTimerTimeout (Timer, mTimeoutTicker) && SyncNeeded;
     )
{
    mSmmMpSyncData->AllApArrivedWithException = AllCpusInSmmExceptBlockedDisabled ();
    if (mSmmMpSyncData->AllApArrivedWithException) {
        break;   // 全コアが揃った → 抜ける
    }
    CpuPause ();  // それ以外は最大1秒待つ
}

攻撃の核心は、この「最大1秒」を1つの命令で食い切ることです。SMI（System Management Interrupt）は命令の境界でしか差し込めません。命令と命令の隙間はすべて、待機中のSMIがコアを引きずり込む「ドア」になります。だから遅延を作るのに複数命令を並べては駄目で、割り込み不可能な単一命令が1秒のランデブーを上回らなければなりません——Assembly Hall of Shame のルール「割り込み可能な命令は失格」が、ここでそのまま前提条件になります。

作者のPoCは、Zen 3の Ryzen 7 5800H で 0xfcc68860 という遅いMMIOアドレスへの幅広い xmm ロードを使い、この1秒のランデブーを破っています。検証は巧妙で、各コアのSMI受信数を性能カウンタ（AMDの MSR_PERF_CTR0）で数え、SMIの嵐を撃ち込んだ後にカウントのばらつき（spread）を見ます。全コアが揃っていれば spread は0（冒頭GIFの「IN LOCKSTEP」）。もし1コアだけSMIを取りこぼしていれば、そのコアはSMMの外で走り続けていた証拠になります。

なぜこれがセキュリティ的に重大なのか。SMMハンドラには、共有メモリ上の値をチェックしてから使うTOCTOU（time-of-check to time-of-use）型の脆弱性が古くから多数知られています（作者は CVE-2021-33164 や CVE-2022-30773 など100件超のSMM TOCTOU CVEを挙げています）。これらの多くが「休眠状態のまま未修正で放置」されてきたのは、悪用に「SMM実行中に共有メモリを書き換える何か」が必要で、ランデブーのおかげでSMMの外にコアが1つも存在しないとされてきたからです。唯一の侵入経路は、CPUの裏で書き込めるDMA対応の周辺機器＝物理アクセスやハードウェアの用意——だからこの脆弱性クラスは「ハードウェアの問題」として片付けられてきました。

SMIの非同期化は、その前提条件を取り除きます。物理アクセスもハードウェアも要らず、ソフトウェアだけで外に残ったコアが、SMM実行中に動ける。すると休眠していたCVE群が、ソフトウェアから踏める可能性のあるものへ変わり得ます。作者自身も「開いたのは窓だけ（悪用そのものは示していない）」と明言しており、本記事もこれ以上の悪用手順・PoCの詳細には踏み込みません。重要なのは、「単一命令をどこまで遅くできるか」という遊びが、そのまま深刻なセキュリティ前提の反例になっているという構造です。

開発者・運用者が学べる教訓と自システムでの確認

このプロジェクトから、手を動かして確認できる教訓を整理します。

まずは自分の環境で split lock 検出がどう構成されているかを確認しましょう（Linux・対応CPU前提）。

# 1) CPUがsplit lock検出に対応しているか（Intel Tremont/Icelake以降などで 'split_lock_detect' が出る）
grep -o 'split_lock_detect' /proc/cpuinfo | head -1

# 2) 現在の起動パラメータでの設定を確認（未指定なら既定=warn）
grep -o 'split_lock_detect=[a-z:0-9]*' /proc/cmdline || echo '未指定（既定: warn）'

# 3) split lock / bus lock がすでに検出されていないかをカーネルログで確認
sudo dmesg | grep -iE 'split lock|bus lock'

# 4) 実行時の緩和挙動を確認（1=警告時に直列化して並行実行を抑制／0=しない）
sysctl kernel.split_lock_mitigate 2>/dev/null || echo 'このカーネルでは未提供'

・1で何も出ない場合：そのCPU（AMDの一部・古いIntel等）はsplit lock検出フラグを提供していません。検出できない＝split lockが起きないという意味ではない点に注意
・2で未指定だった場合：既定は warn です。プロセスを止めたい（テナント分離・リアルタイム保護）なら、起動パラメータに split_lock_detect=fatal、または split_lock_detect=ratelimit:N（0 < N ≤ 1000）を検討します
・3で警告が出ている場合：どのプロセスが撒いているかを特定します。警告メッセージにコマンド名が含まれます

SMM側については、一般ユーザーが自システムで直接テストするのは現実的でも安全でもありません。運用上の要点は次の3つです。

・UEFI/BIOSファームウェアを最新に保つ。SMMハンドラのTOCTOU修正はファームウェア更新で配布されます。「ハードウェアだから安全」という前提はもはや成立しません
・マルチテナント／共有ホスト環境ほど影響が大きい。信頼できないコードと同じ物理CPUを共有する構成では、外に残ったコアが最も危険です
・ファームウェア設計者はランデブー単独に依存しない。「SMM実行中は外に誰もいない」を安全の唯一の根拠にしないことが、この研究の実務的な含意です

より広い文脈として、ローカル権限昇格やコンテナ脱出につながるカーネル層の実例はCopy Fail（CVE-2026-31431）解説｜root奪取・コンテナ脱出とECS/EKS対策で、権限昇格・脱出テクニックの体系的なカタログはGTFOBins：Linuxシステム管理者のための権限昇格・脱出ツール集で扱っています。命令レベルの遅延がバス・キャッシュ・SMMという「共有される資源」を巻き込む点は、これらの権限昇格・脱出の議論と地続きです。

類似プロジェクト・関連ツールとの比較

Assembly Hall of Shame は、作者 Christopher Domas 氏の一連の「x86の底を突く」プロジェクト群の最新作です。関連リポジトリと位置づけを比べると、本プロジェクトが何を新しくしたかが見えます。

補助ツールの扱いにも注意が要ります。各命令のREADMEは、高レイテンシなMMIO領域やMSRを見つけるためのツール（mmiotic・rakefield・nightshyft・portpulse）をクレジットしていますが、確認時点で公開されているのは mmiotic のみで、rakefield・nightshyft・portpulse へのリンクはいずれも404でした（未公開か、これから公開されるものと思われます）。リポジトリの記述をそのまま「全部すぐ使える」と受け取らず、実際にたどって確認するのが安全です。

なお、性能を「速くする」側の定番ツール（Intel VTune、perf、Agner Fog 氏の命令テーブル、llvm-mca など）とは目的が正反対です。それらが最適化のために命令コストを測るのに対し、Assembly Hall of Shame は遅延の下限を意図的に探すことで、普段は見えない「命令がCPUの外まで往復する境界」や「同期前提が崩れる臨界」を可視化します。攻撃ツールではなく、その境界を教材として示すプロジェクトだと理解するのが正確です。

まとめ

Assembly Hall of Shame は「単一のx86命令をどこまで遅くできるか」を競う、遊び心のあるリーダーボードです。しかし27命令を4つの層で整理し、ソースまで読み込むと、2つの明確なセキュリティ境界が現れます。普通のコードから漏れて他コアまで巻き込む split lock（既定の緩和は warn にすぎない）と、1秒を超える1命令がSMMの全コア同期という前提を崩し、休眠中のSMM脆弱性をソフトウェアから踏める窓を開く姉妹研究 smiiiiiiiiiiiiiiii。

AIの切り口はありませんが、低レイヤの命令挙動が「共有される資源（バス・キャッシュ・SMM）」を通じて攻撃面に変わる境界を、これほど具体的な実測値で示す教材は多くありません。数字を引用するときは要約のリーダーボードではなく各命令のCソースとREADMEを、緩和策を語るときはベンダーの主張ではなくカーネル文書の既定値を——一次ソースを当たる価値が、そのまま詰まったプロジェクトです。

参照ソース

・xoreaxeaxeax/asm-hall-of-shame（GitHub・一次ソース／MIT）
・xoreaxeaxeax/smiiiiiiiiiiiiiiii（SMM同期の破壊・一次ソース／MIT）
・Linux Kernel Docs — Bus lock detection and handling（split_lock_detect の既定と挙動）
・TianoCore EDK2 — PiSmmCpuDxeSmm/MpService.c（SMMランデブーの1秒タイムアウト実装）
・Hacker News — Assembly Hall of Shame（議論スレッド）