『RFMコマンドは送られていなかった』──オシロスコープでDRAM通信を覗く「McSee」が暴いたDDR5対策の実態

DDR5規格には、Rowhammer緩和策を支えるための新しいコマンド「Refresh Management（RFM）」が定義されている。だが規格に書かれていることと、実際にCPUが送っている命令が一致しているとは限らない。ETH ZurichのComputer Security Group（COMSEC）が2025年のUSENIX Securityで発表した「McSee」は、DRAMバスを流れる信号を実際にオシロスコープで捉えて検証する解析基盤で、その結果「CPUはRFMコマンドを送っていない」という規格と実装のズレを実証した。

3行まとめ

1. McSeeは、16チャンネルの高速オシロスコープとカスタムのDDR5 UDIMMインターポーザを組み合わせ、DRAMバスの信号を自動でDRAMコマンド列にデコードする解析基盤。取得パイプラインの最適化で、2ミリ秒分の取得時間を898秒から55秒へ約16倍短縮したという。
2. 実測の結果、DDR5規格が定めるRefresh Management(RFM)コマンドは、テストしたCPUから実際には送られていないことを確認。一方でIntel Raptor Lake世代のクライアントCPUには、規格外の独自緩和策「pTRR」が実装されていることを新たに発見した。
3. SledgehammerやRowpressといった既存の高度なRowhammer攻撃を再現・分析し、Rowpressについては先行研究が報告した「17.6倍のACmin削減」に対し、自分たちの環境では「2倍程度」しか再現できなかったとしている。

なぜオシロスコープが必要なのか

これまでのRowhammer研究の多くは、FPGAを使ってDRAMバスの信号を捉える手法をとってきた。だがFPGAは、メモリコントローラそのものの挙動を調べるのには向いていない。McSeeの研究チームは「FPGAではメモリコントローラの振る舞いを研究できないから」という理由で、あえて高速オシロスコープを軸にしたプラットフォームを新たに構築したとFAQで説明している。

McSeeの構成は、16チャンネルデジタイザを備えたオシロスコープと、カスタム設計のDDR5 UDIMMインターポーザ、そしてDDR4/DDR5双方のJEDEC規格に準拠した自作のプロトコルデコーダからなる。取得の流れは、①オシロスコープを設定、②実験ワークロードを実行しながら取得をトリガー、③RAMディスクが満杯になったらデータをデコードサーバーへコピー、④十分なトレースを取得後、残りのファイルもコピーしてCSV化、⑤DRAMコマンド列へデコード、という5段階。オシロスコープの取得パイプラインをボトルネックごとにベンチマークして最適化した結果、2ミリ秒分の取得にかかる時間が当初の898秒から55秒まで縮まったという(論文§7で確認。10個のXMLdigファイルの変換では932秒から55秒、16倍の高速化という記載もある)。

USENIX Security 2025採択版の論文PDF(§4.1 Hardware Components)を直接読むと、ハードウェア選定の経緯も具体的な金額つきで書かれていた。

(出典: McSee論文PDF §4.1をcurl+pdftotextで取得し、該当箇所をgrepで確認)

高価な市販オシロスコープ(約$175,000)を使う一方で、DIMMインターポーザは自作することで市販品の$9,800から約$100まで費用を切り詰めている。研究基盤そのものが「オシロスコープは既製品を買う、治具は自作する」という費用配分になっている点は、COMSECの研究ページ本文だけでは分からなかった具体的な数字だ。

実測1：RFMコマンドは「送られていなかった」

McSeeの目玉となる分析の一つが、DDR5の緩和策を支えるRefresh Management(RFM)コマンドの実装状況調査だ。まずSPD(Serial Presence Detect)チップのデコーダを自作し、30台のDDR5 DIMMからRFM関連のフィールドを抽出したところ、63%のデバイスが有効なRFM値を広告している一方、それを「必須」としているデバイスはわずか3%だった。データシートの確認では、77%のDIMMがオンダイECCの実装を報告しているという。

この「30台中63%が有効なRFM値を広告し、必須とするのはわずか3%」という数字は、論文PDF本文(§6.1)でも「19 of 30 devices (63%) advertise valid RFM... while one of them (i.e., 3%) requires RFM」という記述で一致することをgrepで確認した。一方、GitHub上のアーティファクトリポジトリ(comsec-group/mcsee)のREADMEでは、関連ツール「spd-decoder」の説明として「55% (16/29) advertise valid RFM values but only 14% (4/29) require RFM」という、n数も割合も異なる数字が書かれていた。どちらもRFM周りの実測値である点は共通だが、母数が30台と29台で異なり、割合も一致しない。README側がいつの時点のデータかは明記されておらず、この食い違いの理由は本記事の確認範囲では特定できなかった。論文とCOMSEC公式ページの数字(63%/3%/30台)が一致している以上、本文はこちらを採用する。

続いてメモリコントローラ側を調べるため、McSeeが可能にした新しいビットフリップ手法でIntel Alder LakeとRaptor LakeのDRAMアドレス関数をリバースエンジニアリング。AMD・Intel両方のマシンでRowhammerワークロードを実行しながら観測したところ、いずれのCPUからもRFMコマンドは一切送られていなかった。代わりにIntelは、標準の3.9マイクロ秒というtREFI(リフレッシュ間隔)を実質的に半分にする「ファイングラニュラリティ・リフレッシュモード」を使っていることが判明した。

実測2：Raptor Lakeで見つかった未公表の緩和策「pTRR」

さらに意外な発見として、Raptor Lake上で、ハンマリング対象の行に隣接する行へ時折アクティベーションが送られている現象を観測した。これは、Intelのサーバー向けCPUで以前から報告されていた「pTRR」を思わせる挙動だという。研究チームはこの挙動を統計的に分析し、アグレッサーの隣接行が0.091%の確率で二項分布に従ってリフレッシュされていることを突き止めた。

このpTRRのセキュリティ上の効果も試算されている。Rowhammerの閾値がそれぞれ13,200回・16,700回・18,800回のデバイスにおいて、pTRR保護下でも約50%の攻撃成功確率に達するまでの時間は、それぞれ「1時間未満」「1日」「1週間」だとしている。未公表の緩和策があっても、時間をかければ突破できる確率がそれなりに高いことを示す数字だ。

SledgehammerとRowpressを再現する

McSeeは既存の高度な攻撃の再現・分析にも使われている。複数バンクを並列に叩く「Sledgehammer」の公開実装を再現したところ、6バンクまでは活性化スループットが線形に増加(合計715 ACT)する一方、バンクあたりの活性化数は初期の140から119へやや減少。7バンク以上になると活性化数が大きく落ち込み、TRR回避が難しくなる傾向を確認した。

アグレッサー行を長く開いたままにする「Rowpress」については、実機デモコードを同じマシン上で再現し、1回のアクティベーションあたりのキャッシュブロック読み出し回数を1〜128の範囲で振りながら計測。その結果、行を開いていられる時間は最大292.95ナノ秒で、これによるACmin(最初のビット反転に必要な最小活性化回数)の削減は「2倍程度」に留まり、元の論文が報告していた「17.6倍」という削減効果は再現できなかったとしている。研究チームは「Rowpress効果が存在しないことを示しているわけではなく、実機デモの範囲では行を開いている時間が短いために効果が限定的だっただけで、今後の攻撃改良の余地がある」と補足している。

REFaultを引用する「なぜDDR5でビット反転の報告例が少ないのか」

McSeeのFAQには「AMDがpTRRを実装していないように見えるのに、なぜ最新のDDR5デバイスでビット反転を示す研究がまだ出ていないのか」という問いも用意されている。研究チームはこれに対し、自分たちの別の研究「REFault」を引用し、「REFaultのハンマー回数分析ではDDR5のHC_minはDDR4と同じ範囲に収まっている」「現行のDDR5デバイスは、まだ研究されていないより高度な緩和策を採用している可能性が高い」と回答している。REFault・Blacksmith・ZenHammer・McSeeという一連の研究が、互いに引用し合いながら積み上がっていることが分かる箇所だ。

RFM未実装がAI基盤に持つ意味

McSeeが検証したDDR5のRFM実装状況は、AI学習・推論サーバーのメモリ保護設計を評価するうえでの一次資料になりうる。規格上「対策が入っている」とされるコマンドが、実機のCPUからは送られていないという発見は、AI基盤のハードウェア選定担当者が「規格準拠」を鵜呑みにできない具体例として読める。

GitHubリポジトリと論文PDFはこの加筆で確認できた

初稿の執筆時点(2026年8月28日)では、COMSEC公式研究ページ末尾にあった「McSeeプラットフォームは近くGitHubで公開予定」という記載の真偽を確認できていなかった。今回、github.com/comsec-group/mcseeに実際にアクセスしたところ、リポジトリはすでに公開されており、GitHub API実測(2026年8月29日)でスター6・フォーク0、ライセンスはGPL-3.0、作成日は2025年6月23日、最終更新は2025年6月25日だった。ただしこの本体リポジトリ自体はREADMEと引用情報のみの「ハブ」で、実際のツール群(spd-decoder、ddr5-udimm-interposer-pcb、xmldig2csv-converter、ddr4-decoder、ddr5-decoder、mcsee-experiments、sledgehammerフォーク、rowpressフォークなど)は別組織github.com/mcsee-artifacts配下に分散していることがREADMEから分かった。これらの個別リポジトリまでは今回も未確認で、生のオシロスコープデータもGitHubの容量制限を理由にZenodo(zenodo.org/records/15610916)へ置かれており、Zenodo側のアーカイブ内容も確認していない。

論文PDF(USENIX Security 2025採択版)は本文をpdftotextで抽出し、898秒→55秒の高速化、19/30(63%)のRFM広告率、オシロスコープ本体の型番選定に関する§4.1の記述を直接照合できた。ただし論文中の図表・グラフの画像部分や、§5〜§8の全文まで隅々読み込んだわけではなく、pTRRのリバースエンジニアリング手法の詳細(具体的な統計検定の種類など)は本記事では踏み込んでいない。

4本並べて読んで気づいたこと

今回REFault・Blacksmith・ZenHammer・McSeeの4つの研究ページを続けて読んだが、それぞれの「FAQ」セクションに、前後の研究への言及がそのまま埋め込まれている作りが目についた。McSeeのFAQはREFaultを名指しで引用し、ZenHammerはBlacksmithの知見を踏まえた改良だと明言している。単発の発表を1本ずつ追うより、同じ研究室の連作として時系列で並べたほうが、DDR5のRowhammer耐性がどこまで解明されているかの全体像がつかみやすい。

関連記事

• DDR5はRowhammerに本当に強いのか──ETH Zurichの故障注入基盤「REFault」が出した答え
• Intelだけじゃなかった──AMD Zen系CPUでもRowhammerが刺さることを示した「ZenHammer」
• 全DRAMを殴れるパターンを見つけた研究「Blacksmith」──GPU向けRowhammer攻撃の源流をたどる