この記事は2026-08-15にHacker News APIとGeekNewsフィードで直接確認した項目に基づいています。スコアと順位は変わり続けます。
何が上がっていたか
Hacker News APIで確認した項目です。タイトルは Spaghettifying DRAM、アイテム番号は49286341で、2026-08-15時点で691ポイント、コメント174件でした。リンク先は xoreaxeaxeax/skitter-creek-bath-salts のGitHubリポジトリです。GeekNewsフィードにも同じ項目が並んでいました。
READMEが説明しているのは、DRAMコントローラを触ってCPUのセキュリティ境界を迂回する研究ツールです。
問題は検査ではなく層の順序です
メモリアドレスはCPUからDRAMチップに至るまでに何度も翻訳されます。仮想アドレスが物理アドレスになり、物理アドレスがさらにチャネルとバンクと行と列というDRAM座標になります。最後の変換を担うのがメモリコントローラです。
そして保護装置はそれより上の層にあります。READMEが名指しする対象は、セキュリティプロセッサの専用メモリ、システム管理モードが使う領域、そしてCPUが省電力状態に入るとき内部状態を一時的に置く区間です。これらはOSから見えないように切り出した予約領域で、アクセスを阻む柵が物理アドレス単位で建てられています。
ここで構造的な欠陥が現れます。柵は物理アドレスを見て判断するのに、その物理アドレスがどのDRAMセルに向かうかは柵より下の層で決まります。では下の層の規則を変えてしまうとどうなるか。同じセルが別の物理アドレスからも到達可能になります。そしてその別のアドレスは柵の内側ではないので検査を通過します。
READMEはこの操作をバンクの入れ替えモードとインターリーブ設定を触ることとして説明し、コントローラのレジスタのビットを1つ反転させる形の例を示します。要点は精巧な攻撃連鎖ではなく設定値1つだという点です。
別名をどうやって見つけるのか
問題は入れ替え規則が文書化されていないことです。設定を変えればアドレスが再配置されるとわかっても、どのアドレスがどのアドレスと同じセルを指すかはわかりません。
READMEが説明する手順は観測と逆算です。まずスクランブリングのモードをいろいろ切り替えながら別名の組を集めます。2つの物理アドレスが同じDRAM位置を指すという事実は、片方に書いてもう片方から読めば確認できます。こうして事実を十分に集めます。
次がこの研究の技術的な核心です。アドレスの入れ替えはビットの排他的論理和の組み合わせで表現されるので、これはGF(2)上の線形変換です。つまり観測した別名の組は未知の行列に対する方程式になり、SMTソルバに入れればその行列を復元できます。
行列を得ると方向が反転します。今度は保護領域内の特定のアドレスを目標に置いて、そのセルに到達する別の物理アドレスを計算できます。READMEが題に使ったスパゲッティという表現がこれで、ツール名に入った巻き戻しがその逆演算です。
読み出せるものとしてREADMEが挙げる例は具体的です。セキュリティプロセッサ側ではファームウェアTPMのRSAエンジン、システム管理モード側では割り込みハンドラの入口ベクタ、省電力予約領域では保存されたCPUレジスタとマイクロコードパッチです。
範囲を正確にする必要があります
ここで誇張を取り除く必要があります。コメントで最初に確認されたのもこの部分でした。
第一に、すでにroot権限が必要です。複数のコメントがこれを確認し、READMEの実行手順も管理者権限を前提にしています。つまりこれは権限昇格の脆弱性ではありません。すでに最高権限を得た攻撃者が、それよりさらに下にあるはずの領域まで到達するという話です。
第二に、対象が1つのCPUファミリです。READMEはAMD Family 16hのみを扱い、その理由をデータシートがDRAMコントローラの変換レジスタを文書化した最後の世代であり、それがロックされないことを示しているからだと述べます。コメントではこれが2013年頃の低消費電力アーキテクチャである点と、最新世代で通用するかについての言及が事実上ない点が繰り返し指摘されました。README自身も17h以降に適用されるかは不明と書いています。
第三に、プラットフォームごとに準備が異なります。あらかじめ計算したマッピングファイルが必要で、DIMM構成が違えばマッピングを作り直す必要があります。
3つを合わせると実際の脅威モデルはこうです。遠隔の攻撃経路ではなく、物理的にアクセスでき、すでにrootを持っている特定の旧世代ハードウェアからリング マイナス2より下の秘密を取り出す研究です。コメントでゲーム機が言及されたのも、その脅威モデルが正確に当てはまるからです。攻撃者が機器を手にしていて、カーネルを取るのは難しい代わりに、取った後はその下が防御の最終線だからです。
この話が自分たちのシステムに残すもの
ほとんどの読者はDRAMコントローラを触りません。しかしこの研究の形はハードウェアの外でも繰り返されます。
一般化するとこうです。N層で強制した規則は、攻撃者がN-1層で動けるなら無効です。そしてこの失敗は規則が間違っているからではなく、規則が参照する名前が下の層で解釈し直されるために起きます。
同じ形はソフトウェアですぐ見つかります。パス文字列でアクセスを止めているのにシンボリックリンクがそのパスを別の場所へ送る場合、URL文字列で検査したのにライブラリが違う正規化をする場合、コンテナ名でポリシーをかけたのにマウントがその下で別のファイルを見せる場合は、すべて同じ構造です。
そこで実務に持ち帰る点検が1つあります。自分たちのアクセス制御が判断の根拠にしている名前を、その判断のあとで誰が解釈し直すのか。判断と実際のアクセスの間に翻訳の段が1つでも挟まっていて、その段を攻撃者が触れるなら、検査は飾りです。この観点はハードウェアバックドアとは実際に何かで扱った筋道につながります。
2つ目の点検は文書化とロックの関係です。この研究が特定の世代を選んだ理由はその世代がレジスタを文書化していたからですが、裏返せば文書化しなかっただけでロックされていない設定は次の世代にも残っている可能性があります。ドキュメントから消すことは防御ではありません。
誰には当てはまらないか
マネージドクラウドでアプリケーションを運用するチームにとって、この項目は直接の対応対象ではありません。物理アクセスとrootを前提とするからで、その前提が成り立つ時点ですでに他の問題のほうがはるかに大きいです。
最新のサーバCPUだけを使う環境も同様です。対象が2013年頃の特定ファミリで、以降の世代についての検証はREADMEにありません。
逆に実際に気にすべき側は明確です。攻撃者が機器を物理的に所有する製品、すなわちキオスク、セットトップボックス、ゲーム機、現場設置機器、そして組み込みボードです。こうした製品でファームウェアTPMやセキュリティプロセッサを信頼の基盤にしているなら、その信頼がどの層の柵に依存しているか確認する価値があります。
まとめ
このリポジトリが示すのは新しい暗号解読ではなく配置の誤りです。柵をアドレス変換より上に建てれば、変換を変えられる人にとってその柵は無いのと同じです。そして範囲は正直に狭いです。rootが必要で、1つのCPUファミリで確認され、プラットフォームごとに準備が異なります。残る教訓は特定のチップではなく層の順序です。
原文と関連記事
- skitter-creek-bath-salts リポジトリ — メモリコントローラ段と保護の柵の層関係、バンク入れ替えとインターリーブの操作、別名の組の収集とGF(2)線形代数およびSMTソルバによる復元、読み出した対象の一覧、AMD Family 16h限定と以降の世代が未検証である点、事前計算マッピングが必要という限界
- Hacker News の議論 — 2026-08-15時点で691ポイント、コメント174件。root権限が前提であることの確認、対象アーキテクチャの年代と最新世代への適用可否の質問、コンソールセキュリティの観点
- このブログの関連記事: ハードウェアバックドアとは実際に何か · 命令のレイテンシは命令の属性ではない · 主記憶 · 保護
- 前の記事: Cerebras Ultrafastとエージェントループのボトルネック
- 次の記事: 理解がボトルネックだという主張とその循環
層の順序についての一般化とソフトウェア側の事例は、リポジトリの文書で確認した内容をもとに筆者が整理したものです。
현재 단락 (1/31)
Hacker News APIで確認した項目です。タイトルは `Spaghettifying DRAM`、アイテム番号は49286341で、2026-08-15時点で691ポイント、コメント174件で...