トロント大学がGPUThor攻撃を公開、Nvidia GPUのECC防護を突破

トロント大学の研究者らは8月下旬、Nvidia製GPUに組み込まれたECC（誤り訂正符号）保護を回避できる新たな攻撃手法「GPUThor」を公開した。Rowhammer攻撃の原理に基づくこの手法は、Ampereアーキテクチャを採用しGDDR6メモリを搭載するワークステーション向けGPU——RTX A4000、A4500、A5000、A6000——で検証されており、これらはAI・クラウドインフラで広く使われているモデルだ。研究チームは4月29日にNvidiaへ脆弱性を報告し、Nvidiaは約4カ月の協調的な情報開示期間を経て、8月25日に緩和策のガイダンスを公開した。

AI向けGPUにECCが不可欠な理由

高負荷が続くメモリチップでは、宇宙線や電気的干渉、製造上の欠陥などにより、ランダムに「ビット反転」（bit flip）が起きることがある——0として保存されていたビットが誤って1に、あるいはその逆に変化する現象だ。一般的な用途では、単発のビット反転が問題になることは少ない。しかしAIの学習や推論では、重み、勾配、活性化値が直接書き換えられ、学習結果が静かに歪んだり、推論時にもっともらしいが誤った出力が警告なしに生成されたりする恐れがある。ECCはまさにこれを防ぐための仕組みだ。各メモリブロックに追加の検査コードを保存することで、システムは1ビット誤りを自動的に訂正し、2ビット誤りを検出する——SECDEDと呼ばれる方式だ。この保証があるからこそ、クラウド事業者は同一の物理GPUを複数の顧客で安心して共有させられる。

GPUThorはどうやってECCを突破するのか

GPUThorは意図的に不均一（non-uniform）なパターンでメモリを「ハンマリング」しながら、Nvidiaがこれまで文書化していなかった2つのGPUの挙動を悪用する。すなわち、繰り返されるメモリアクセス要求をGPUがどう結合（coalesce）するか、そしてGDDR6メモリのTarget Row Refresh（TRR、対象行リフレッシュ）機構が実際にはどの頻度で作動するかだ。TRRの検出しきい値をぎりぎり下回る水準を保つことで、GPUThorは標的となるメモリ行を継続的に「叩き」続け、隣接する行にビット反転を引き起こす。

• ECCを無効にした検証対象GPUでは、GPUThorはメモリ1GBあたり72,000から377,000回のビット反転を発生させた——研究チームの以前の攻撃GPUHammerと比べ最大23,597倍に達する。
• ECCを有効にしていても、GPUThorは387件の「2ビットエラー」（ECCは検出できるが訂正はできない）と、2件の「3ビットエラー」（ECCの訂正能力を超え、誤訂正によってデータが破損する）を発生させた。
• 悪用可能なビット反転を見つけるまでの時間は平均約1.1分に短縮された。GPUHammerでは21.9時間を要していた。
• ECCを有効にしたRTX A6000への継続的な攻撃は、GPUを2時間ごとに強制リセットさせ、実行中の全ての処理を中断させうる。攻撃を繰り返すと、カード自体が交換が必要だと自己申告する状態にまで至る。

サービス拒否（DoS）にとどまらず、研究者たちはさらに深刻な結果も示した。GPUのページテーブルを改ざんすることで、特別な権限を持たないCUDAプログラムが任意のメモリアクセス権を獲得し、ホスト側でrootシェルを開くことができる——ごく普通のGPU計算タスクが、サーバー全体の完全な制御につながりうるということだ。A100のようなデータセンター向けAmpere GPUはDoSに対しては比較的耐性があるものの、権限昇格には依然として脆弱であり、RAS Repair保護を備えたBlackwell世代のGPUでさえ、攻撃を防げるわけではなく時間がかかるようにするだけだ。研究者らは、オンダイECCを備えた将来のGDDR7やHBM3e搭載GPUについても、複数ビット反転の状況下では脆弱性が残る可能性があると警告している。

実際に危険にさらされているのは誰か

GPUThorが狙うのは個人のPCではなく、AIの学習・推論を支えるデータセンターのGPUクラスタ、とりわけ複数の顧客が同一の物理GPUを共有するマルチテナント型のクラウドGPUインスタンスだ——これはパブリッククラウドのGPUサービスの大半で採用されている標準的な仕組みでもある。攻撃者がわずかな計算時間を借りるだけで、同じハードウェア上で稼働する他の顧客のAI学習・推論タスクを妨害、あるいは改ざんできる可能性があり、アプリケーション層からは検知しづらいサプライチェーン型のリスクとなる。Nvidiaのガイダンスは隔離と監視に重点を置いている。SYS-ECCおよびIOMMU／DMA隔離の有効化、GPUエラーテレメトリの継続的な監視、そして信頼できないCUDAワークロードの同一ハードウェアでの共有制限などだ。

日本企業にとって何が変わるのか

AWS、Microsoft Azure、Google Cloudなどのクラウド事業者からGPUインスタンスを借りてAIモデルの学習・運用を行っている日本企業にとって、API呼び出しの背後にある物理GPUがほぼ確実に他のテナントと共有されているという事実は、あらためて意識すべき点だ。GPUクラウドのインスタンスを最初から信頼できる隔離環境だと決めつける前に、セキュリティ・インフラ部門はNvidiaが推奨するSYS-ECCとIOMMU／DMA隔離が実際に有効化されているかを提供事業者に確認し、GPUエラーテレメトリの可視性を求め、マルチテナントGPUの隔離リスクをベンダーセキュリティ審査の正式な項目として組み込むべきだろう。スペックシート上のチェック項目としてではなく、共有GPUが実際にどう保護されているのかという実質的な問いとして扱う必要がある。