Dynamic Rowhammer Threshold Management:Temperature-Aware Threshold Degradation for In-DRAM Defenses

技術要約：動的Rowhammer閾値管理

問題提起
Rowhammer脆弱性は、ビット反転を誘発するために必要な最小行アクティベーション数であるRowhammer閾値（$T_{RHD}$）によって特徴付けられ、DRAMの世代が進むごとに激化しています。$T_{RHD}$は、2014年の約139Kから、現代のDDR4では4.8K未満に低下し、DDR5では1Kを下回ることが目標となっています。現在のイン・DRAM防御策（Target Row Refresh [TRR]、Per-Row Activation Counting [PRAC]、SALT-C）は、アクティベーションを追跡し、固定された閾値を超えた際に被害行をリフレッシュすることでこれを緩和しています。

しかし、これらの防御策は製造時に静的な$T_{RHD}$値を用いてパラメータ化されるため、「閾値の陳腐化（threshold staleness）」という重大な脆弱性が生じます。これは、真の$T_{RHD}$が動作条件、特に温度によって大きく変動するためです。SpyHammer [6] の集計データは、ビットエラー率（BER）と温度（50–95°C）との間にほぼ線形な依存関係があることを示しており、モジュール内のBERにおいて最大3.3倍の開きが生じます。さらに、VRD [7] は、閾値が時間の経過とともに確率的に変動することを示しています。その結果、公称65°Cの環境向けに校正された防御策は、システムが高温（例：85°C）で動作している際に、実質的な緩和が不十分な状態になり、構成された閾値が実際の物理的条件に対して緩すぎるという、悪用可能な窓口を生み出す可能性があります。

手法
著者らは、既存のカウンタベースの防御策を後付けする、防御策に依存しないランタイム層である**動的Rowhammer閾値管理（Dynamic Rowhammer Threshold Management）**を提案しています。これは新しい防御メカニズムを導入するのではなく、各エポック（デフォルト10 ms）ごとに観測された温度に基づいて、既存の防御策の閾値パラメータを動的に再供給する層です。

本手法は以下の3つのコンポーネントで構成されます：

1. 動的 $T_{RHD}$ モデル: 有効閾値（$T_{RHDeff}$）は次のように計算されます：
   $$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$$
   • 温度係数 ($f_{temp}$): SpyHammer [6] のデータを用いた線形回帰から導出され、温度上昇に伴う $T_{RHD}$ の劣化をモデル化します。このモデルは、メーカーID（MID）に基づくルックアップテーブルを介して、ベンダー固有の差異（例：Samsungの反転符号）を処理します。
   • ガードバンド ($g$): 確率的な時間的変動（VRD [7]）や、集団平均の温度モデルでは捉えきれない行ごとの分散を考慮するための、乗法的デレーティング係数（経験的に0.9に設定）です。
2. エポックごとの更新手順: コントローラはSPDサイドのセンサ（DDR4）またはSPD-Hubセンサ（DDR5）から温度をサンプリングし、$T_{RHDeff}$ を計算して、稼働中の防御策の特定の閾値変数にこの値を投影します。
3. 閾値の投影: この層は、計算された $T_{RHDeff}$ を各防御策の特定のセキュリティ契約にマッピングします：
   • SALT-C: 最大アクティベーション数（$MaxACT$）が劣化した物理的閾値を下回るように、Activation Per Minute（APM）パラメータを再計算します。
   • PRAC: 行ごとのアラート閾値（$ATH_{PRAC}$）を、ABOグレース予算から $T_{RHDeff}$ を差し引くことで調整します。
   • TRR: 固定深度トラッカーの閾値を $T_{RHDeff}/2$ に調整します。

決定的なことに、この層は常に閾値を厳格化する方向（決して緩和しない方向）にのみ作用し、基礎となる防御策の正当性の議論を維持します。

主な貢献

1. 防御策に依存しないランタイム層: 閾値パラメータを静的な製造定数から切り離し、コアとなる防御ロジックを変更することなく、実行時の熱条件に適応させるメカニメント。
2. 統一評価フレームワーク: 「デカップルド・オラクル（decoupled oracle）」を用いた3つの異なる防御アーキテクチャ（SALT-C, PRAC, TRR）への評価。このオラクルは、物理的な $T_{RHD}$ を確率的因子 $\delta \sim N(1, \sigma)$ で各DIMMごとにスケーリングすることで、モデルの自己整合性を打破し、評価がモデルの内部的な仮定ではなく、現実世界の変動を扱う能力をテストするように設計されています。
3. ハードウェア実現可能性分析: 論文では2つの展開パスを概説しています。一つはJEDEC標準の更新（各バンクの閾値レジスタの露出）を必要とするホスト側実装、もう一つは既存の内部熱センサとROMテーブルを使用し、新しいホスト書き込み可能レジスタを回避するオンダイ実装です。

結果
評価は、DRAMSim3を用い、ダブルサイドRowhammerトレース（60万アクティベーション）および700万サイクルを用いて実施されました。

• PRAC: 公称静的構成（65°Cで校正）は、85°Cにおいて72回の侵害が発生しました。動的層は、$\sigma=0$ の場合にこれを0回に減少させました。確率的変動（$\sigma=0.10$）がある場合でも、ガードバンド（$g=0.9$）を用いた動的層は、侵害数を38.4（$g=1.0$ の時）から9.6へと減少させました。
• SALT-C: 公称静的構成は、85°Cにおいて10回の侵害が発生しました。動的層はこれを2回（初回のエポックによる過渡現象に起因）に減少させ、初期温度に基づいて閾値をシードするブートストラップ・ポリシーを用いることで0回に排除しました。動的動作によるレイテンシコストは、85°Cにおいて公称静的構成と比較して5.1%増加しましたが、65°Cにおけるワーストケースの静的構成（85°C用に校正されたもの）よりも3.6%低コストでした。
• TRR: この層は主にTRRの診断ツールとして機能しました。小さなトラッカー深度（$K=4$）では、閾値の陳腐化ではなく容量制限（追い出し）が原因で、校正に関わらず高い侵害数が発生しました。この層は、トラッカー深度を増加させた場合（$K \ge 16$）にのみ効果を発揮しました。
• オーバーヘッド: 計算コストは無視できる程度です（計算に1 ns未満）。支配的なコストは、新しい閾値を各バンクのレジスタに書き込むために必要なメモリ帯域幅であり、10 msのエポックあたり約260 ns（DRAM帯域の0.003%）と推定されます。

意義と主張
本論文は、動的Rowhammer閾値管理が、静的な防御策を高温の動作環境下で脆弱にする「熱的陳腐化」のギャップを埋めるものであると主張しています。薄いランタイム層を用いることで、DRAMアーキテクチャや防御アルゴリズム自体の根本的な再設計を必要とせずに、既存の防御策のパラメータリングを遡及的に修正できることを実証しています。

著者らは以下の制限事項を明示しています：

• 結果はシミュレーションベースであり、展開には温度に対する $HC_{first}$（最初のビット反転までのアクティベーション数）のオンシリコン特性評価が必要です。
• 線形温度モデルはDDR4のデータから導出されており、プロセス変更に伴う再適合なしにはDDR5に一般化できない可能性があります。
• 本手法は、観測された温度が実際のセル温度を反映していることを前提としており、センサのスプーフィング（偽装）や熱操作攻撃に対して脆弱です。ただし、オンダイセンサの実装によってこれは軽減されます。
• この層は、非カウンタベースの防御（例：row-swap）や、BlacksmithやZenHammerのような特定の攻撃パターンには対処しませんが、これらとは直交するものと期待されます。

最終的に、本研究は新しい防御策としてではなく、カウンタベースの防御策のパラメータが動的な熱条件下で有効であり続けることを保証するための、必要なランタイム管理層として位置づけられています。