ハクソク

世界を動かす技術を、日本語で。

GPUHammer: GPUメモリに対するRowhammer攻撃は実用的である

314日前原文(gpuhammer.com)

概要

  • GPUHammer は、GPUメモリ（GDDR6）で世界初の Rowhammerビット反転攻撃 を実証
  • ユーザーレベルのCUDAコード で、NVIDIA A6000上の全DRAMバンクにビット反転を誘発
  • 攻撃により、GPU上で他ユーザーのデータやDNNモデルの改ざんが可能
  • ECC有効化 で緩和可能だが、最大10%の性能低下を伴う
  • 詳細は USENIX Security 2025論文、GitHubおよびZenodoで成果物公開

GPUHammer: GPUメモリに対するRowhammer攻撃の実現性

  • Rowhammer は、特定のメモリ行を高速にアクティブ化することで隣接行に ビット反転 を生じさせるハードウェア脆弱性
  • 従来はCPU（DDR3/DDR4/LPDDR4）で研究されてきたが、 AI/MLワークロードのGPU移行 によりGPUメモリの脆弱性評価が急務
  • GDDR6メモリ は、CPU用DDR4より高レイテンシ・高速リフレッシュ・不明瞭なアドレスマッピング・非公開のDRAM防御機構といった障壁が存在
  • GPUHammer は、これらの障壁を克服し、GDDR6上でRowhammer攻撃を実現

手順1：GPU DRAMアドレスマッピングのリバースエンジニアリング

  • NVIDIA GPUでは、物理アドレスが非公開のため 同一DRAMバンク にマッピングされる仮想アドレス特定が困難
  • NVIDIAドライバの仮想-物理マッピングの一貫性に着目し、 DRAMA手法 を応用
  • メモリアクセスのレイテンシ差から同一バンクアドレスを抽出
    • NUMA効果によるレイテンシの重複を除外し、 同一バンクペア を明確化

手順2：ハンマリング強度の最大化

  • GPUメモリアクセスはCPUの最大4倍遅く、 シングルスレッド では必要なアクティベーションレートに到達不可
  • GPUの SIMT並列性 を活用し、マルチスレッド・マルチワープで同時実行
    • メモリコントローラのアイドル時間を削減し、 最大ハンマリングレート を達成

手順3：リフレッシュ同期と防御回避

  • 先行研究（SMASH/BlackSmith）から、 リフレッシュ同期 がDRAM防御回避の鍵と判明
  • CUDAの同期プリミティブではワープ実行順序が乱れるため、 ワープ毎の遅延挿入 でリフレッシュとハンマリングを同期
    • TRR等の インDRAM防御 を回避しつつ、ワープ順序の維持を実現

実証結果と攻撃効果

  • NVIDIA RTX A6000（48GB GDDR6）で全4バンクに対し 8件のシングルビット反転 を観測
  • 最小アクティベーション回数（TRH）は約12,000回で、DDR4の先行事例と同等
  • MLモデル精度劣化攻撃 を世界初実証
    • FP16重みの指数部ビット反転で、ImageNetモデル5種の精度を80%→0.1%まで低下
    • 単一ビット反転 で大幅な精度劣化を誘発可能

よくある質問（FAQ）

  • どのGPUが脆弱か？

    • NVIDIA A6000（GDDR6）でビット反転を確認
    • RTX 3080（GDDR6）では未確認、A100（HBM）も未確認
    • DRAMベンダ・チップ特性・温度等で挙動が異なる可能性

  • なぜテストGPUが少ないのか？

    • GPUのDRAMは基板直付け・高額で大規模検証が困難
    • 攻撃コードは他Ampere世代GPUにも拡張可能、今後の研究に期待

  • GPUHammerの緩和策は？

    • ECC有効化 （nvidia-smi -e 1、再起動必要）で全ビット反転を訂正可能
      • ただし性能最大10%低下、メモリ容量6.25%減少
      • 根本解決にはGDDR6自体のハードウェア設計見直し（PRAC/PRIDE等）が必要

  • H100やRTX 5090等の新世代GPUは安全か？

    • 現状は オンダイECC 搭載で単一ビット反転はマスクされる見込み
    • 将来的にマルチビット反転パターン（ECCploit等）が現れる可能性

  • NVIDIAへの情報開示と対応は？

    • 2025年1月15日、NVIDIAおよび主要クラウド事業者に責任ある開示を実施
    • NVIDIAは問題を認め、ECC有効化を推奨

参考情報・論文引用

  • 詳細は USENIX Security 2025論文、GitHubおよびZenodoで成果物公開
  • 論文引用例：
    • @inproceedings{lin2025gpuhammer, author = {Chris S. Lin and Joyce Qu and Gururaj Saileshwar}, title = {GPUHammer: Rowhammer Attacks on GPU Memories are Practical}, publisher = {USENIX Association}, booktitle = {Proceedings of the 34th USENIX Conference on Security Symposium}, year = {2025}, series = {SEC '25}, address = {USA}, location = {Seattle, WA, USA}, }

謝辞

  • 本研究はカナダ自然科学・工学研究会議（NSERC）等の支援によるもの
  • 内容は著者個人の見解であり、NSERC等の公式見解ではない

Hackerたちの意見

ハードウェア初心者なんだけど、こういう問題が開発中にEMシミュレーションを通過する理由について知ってる人いる？最近のチップは複雑すぎて完全な形式検証は無理だってのは分かるけど、メモリモジュールは構造がかなり規則的だから、もしかしたらそこでは可能かもって思ってたんだよね。

└

この分野の専門家じゃないけど、元々のローハンマー問題（とその後の部分的なハードウェア対策）を読んだ限りでは、高速で密度の高いRAMを市場に出す方が、証明可能な耐改ざん性を持つものを設計するよりも良いと見なされていたみたい。GPUは常に「すぐに消費者に届ける」方針で、宇宙線に耐えられるようなNASA的なエンジニアリングとは違うと思う。EMシミュレーションでそれを見つけられると思うけど、ローハンマーの前は誰もチェックしようと思わなかったか、もしくはランダムなデータ入力や一般的なデータでシミュレーションをチェックしてたんじゃないかな。今まで考えられなかった攻撃ベクトルを考慮してなかったってことだと思うけど、最近のハードウェアについてはそれじゃ説明がつかないね。

└

ヘッドラインに驚かなかったから、Nvidiaのエンジニアもよくわかってたんじゃないかな。完璧なものなんてないし、すべてに失敗条件があるからね。問題は、どこに基準を置くかだよ。コンポーネントを60℃、80℃、それとも100℃で動かしたいの？高放射線環境で動作させたいの？異常なアクセスパターンに耐えられるようにしたいの？つまり、$/GBのRAMが倍になっても、Rowhammer攻撃に耐えられるGPUの市場は十分じゃないってことだね。

└

RowhammerはDRAMの設計方法に内在する問題なんだ。メモリメーカーには知られている問題で、修正が非常に難しいか、ほぼ不可能なんだよ。実際、Rowhammerはメモリの密度が増すにつれて悪化するだけなんだ。

これは、GPUを計算目的でテナント間で分けるような大きなワークロードがあることが前提になってるみたい。誰か大きな例を持ってる？思いつく限りでは、専用GPUになることが多いんだけど。

└

WebGPU APIでデスクトップ全体のスクリーンショットを取る感じ？

└

多くのGPUレンタル会社は、共有GPUワークロードに対して料金が安いんだよね。だからコストと計算のトレードオフってこと。通常は、全てのRAMを一つのインスタンスで必要としない限り、ワークロード自体がフルGPUを必要とするわけじゃないよ。

└

GKEでは、パーティション化されたりタイムシェアされたスキームで、単一のGPUを複数のコンテナで共有できるよ。: https://cloud.google.com/kubernetes-engine/docs/concepts/tim...

└

NVIDIAのGPUはMIG（マルチインスタンスGPU）で動作できて、GPUよりも多くのジョブを詰め込むことができる。HPCでは非常に一般的だけど、クラウドではどうかは分からないな。

└

例：デスクトップのレンダリングとGPGPUの処理（深層ニューラルネットワークみたいな）に使うワークステーションやコンシューマーGPU。

└

アップデート：一瞬、JupyterノートブックサービスでGPUを使ってるのかと思ったけど、Google Colabを見たら、そっちでもそのセッション専用のGPUなんだよね。* 余談だけど、Colabの計算クレジットが90日で期限切れになるのって合法なの？カリフォルニアでは企業の通貨が期限切れになるのは禁止されてると思ったんだけど。（ギフトカードみたいに）

└

俺の（限られた）理解では、業界は以前からテナント間でGPUを共有するのが安全じゃないことを知ってたから、主要なクラウドプロバイダーは専用GPUしか売ってないんだよね。

GPUがグラフィックスのレンダリングにしか使われてなかった頃は、VRAMの偶発的なビットフリップなんて誰も気にしてなかったよね。ECCを有効にするとパフォーマンスが落ちるのは奇妙だと思う。ECCエラーが修正される場合だけの話なら分かるけど、CPUの場合はエラーを修正しても速度に違いはないはず。概念実証では、これらのビットフリップを使って被害者のDNNモデルを改ざんして、モデルの精度を80%から0.1%に下げることができるんだ。一つのビットフリップでね。確率的モデルに対してこれをやるのは皮肉だよね。本来不正確でエラーが起こりやすい現実を模倣するために設計されてるのに。

└

ECCメモリは、非ECCメモリよりも遅いことが多いよ。MT/sも遅いし、レイテンシも高い。特に「プロシューマー」向けのECC UDIMMについてはね。だから、ECCをオンにすると帯域幅が下がるのもそんなに驚くことじゃないと思う。

└

Nvidiaは、ハードウェアにECCを実装するために必要な追加のメモリチップをボードに加えたくなかったから、ソフトウェアでECCを実装してるんだ。ハードウェアでECCを使うのはHBMメモリの時だけだよ。とはいえ、GDDR7にはオンダイECCがあって、現状ではそれが免疫を与えてる。オンダイECCから修正されたビットフリップの情報は得られないけど、何もないよりはマシだね。

俺の4090 Nvidia RTXのECCモードでこれが止まるの？

└

そうだけど、パフォーマンスが落ちるし、あなたがマルチテナントのワークロードを運営しているクラウドプロバイダーじゃない限り、気にする必要はないと思う。最悪の場合、誰かがwebglを使ってこれを実行して、ウェブサイトがあなたのVRAMを破損させることができるかもしれない。でも、そのシナリオでは実際に何かを盗むことはできない（私の知る限り）から、ただのちょっとした不便に過ぎないよ。

└

AppleのMシリーズはどうなの？

ハンマー攻撃って、メタフィジカルな視点から見てもめちゃくちゃ満足感があると思う。閉じたバーチャルユニバースから抜け出すのは、伝統的な意味で「抜け出す」んじゃなくて、VMハイパーバイザーの境界にあるバグを利用して、バーチャルユニバースの基盤となる物理法則を直接操作することで、パターンを作るだけなんだよね。どんなにバーチャルなデジタル層があっても、基盤となるアナログの基盤に影響を与えられれば、これがうまくいくかもしれない。自分たちの宇宙にも同じようなことがあるんじゃないかって夢見ちゃうよね？

└

自分たちの宇宙にも同じようなことがあるんじゃないかって夢見ちゃうよね？ それはLHCが達成していることだと思ってる：宇宙の基本的な構成要素を極端なエネルギーでぶつけ合って、宇宙の基盤に波紋を起こすってやつね。

└

地球の生命にはいくつかの方法があるけど、進化はそれらをすべて利用することを学んだんだよね。

└

壁を10万回叩いてみたら、隣の部屋に影響を与えたみたい。どうやらこのバーチャルな家の抽象化は詐欺だったみたい。

└

「ハンマー攻撃って、めちゃくちゃ満足感があると思う」 哲学的には同意するけど、実際的にはパフォーマンスがまた落ちるかもしれないと思うと悲しいね。

└

もし私たちがシミュレーションの中にいるなら、SysRqやCtrl-Alt-Deleteに相当する方法は無限にあるよ。0.9cで物体を動かすみたいなシンプルなことすら試してないしね。

└

どれだけバーチャルなデジタルレイヤーがあっても、GPUプログラムが高エネルギー物理学のツールにアクセスせずに物理の脆弱性を見つけられるって言ってるの？それはちょっと信じがたいな。

└

自分たちの宇宙にも同じようなものがあるかもしれないって夢見ちゃうよね？でも、実際に気づくことができるのかな？私たちにとっては、ただの物理学が増えるだけだし。

└

自分たちの宇宙にも同じようなものがあるかもしれないって夢見ちゃうよね？私のシミュレーションを攻撃するアイデアは心理的なもので、自分たちのシミュレーションを作って、それがさらに別のシミュレーションを作るって感じ。そうすれば、シミュレーターたちが自分たちもシミュレーションなんじゃないかって疑念を抱くようになるし、私たちの苦境に共感してくれるかも。

一般的なケースでは、最適化されたアセンブリで書かれた機械語が、遅いコンパイラ生成の機械語に比べて問題になることがあるんだよね（もちろん、いつもそうとは限らないけど）：この機械語がメモリを「ハンマー」している場合、最適化されたアセンブリの機械語の方が、実際にテストされたコンパイラ生成の機械語よりもその可能性が高いかもしれない。