ロウハンマー (row hammer, rowhammer) は、ダイナミックRAM (DRAM) に起きる意図的でない副作用で、複数のメモリセル から電荷が漏れ出し、メモリセル間で電気的な相互作用が起きるために、元のメモリアドレス で指定されていない近くの行 の内容が変化する可能性があるという現象(行間干渉 )である。このようなメモリセル間の分離の回避は近年のDRAMのメモリセルの密度の高さに起因しており、同じ行を何回もすばやく有効にするよう特別に細工されたメモリアクセスパターン (英語版 ) によって引き起こされることがある
[ 1] [ 2] [ 3] 。
ロウハンマーはコンピュータ・セキュリティで権限昇格 (英語版 ) に悪用(→エクスプロイト )されており
[ 2] [ 4] [ 5] [ 6] 、
攻撃者と被害者が高速ネットワークで接続されている場合にはネットワークベースの攻撃も理論的には可能である
[ 7] [ 8] 。
ロウハンマーを防ぐいくつかの異なるハードウェア ベースの技法が存在する。これにはDRAM メモリモジュール (英語版 ) のタイプとプロセッサ によるサポートを必要とするものが含まれる。
[ 9] [ 10]
ロウハンマーはDDR やDDR2 SDRAMモジュールではほとんど、または全く影響しないが、多くのDDR3 やDDR4 SDRAMモジュールには影響を及ぼす。
DRAM の高次構造を図示したもの。青い四角がメモリセル 、緑の長方形がアドレスデコーダ (英語版 ) 、赤い四角がセンスアンプ 。
DRAMの内部では、格納されたデータの各ビット は1個のキャパシタ(コンデンサ )と1個のトランジスタ で電気的に実装された独立なメモリセルを占有する。キャパシタの充電状態(充電されているかいないか)によりDRAMメモリセルが2進値 "1"を持つか"0"を持つかが決まる。集積回路 には膨大な数のDRAMメモリセルが、データの読み書きとリフレッシュ のためにセルを編成する付加的なロジック回路と共に詰め込まれている
[ 11] [ 12] 。
さらに、メモリセル(イラストでは青の四角)は行列 に編成され、行アドレスと列アドレスによって選択される。メモリアドレス は行アドレスデコーダ (英語版 ) と列アドレスデコーダ(イラストではそれぞれ垂直と水平な緑の長方形)によって行アドレスと列アドレスに分割される。読み出し動作では行の行アドレスが選択された後(この選択は行アクティベーション とも呼ばれている)、この行のすべてのメモリセルからのビットは行バッファ (イラストでは赤い四角)を構成するセンスアンプ に移されて、ここから列アドレスによって1ビットが選び出される。その際に読み出しの動作はメモリセルの内容を破壊してしまう性質を持つ。そこでDRAM の設計ではメモリセルの電荷を行バッファに移して読み出した値をその後に再びメモリセルに書き戻す動作をする。書き込み動作でも同様にしてアドレスを解釈するが、1ビットの変更であっても行全体を再書き込みする構造になっている
[ 1] :2–3 [ 11] [ 12] [ 13] 。
自然放電するキャパシタを用いてデータを保持するため、DRAMのメモリセルは時間とともにデータを失っていくので、周期的にすべてのメモリセルを書き込み直す必要がある。これはメモリリフレッシュ動作 (リフレッシュ)と呼ばれている。
DRAMの構造上、宇宙線 その他の影響を受けて保持したデータがランダムに変化するソフトエラー (英語版 ) と言う誤動作が起きやすい。
誤動作対策にはいくつかの技法があり、DRAMの信頼性を向上させている。よく使われるものにはECCメモリ やその改良版(ロックステップメモリ (英語版 ) など)がある
[ 14] 。
黄色の行の高速な動作は紫色の行(被害行)内のビット値の変化を引き起こすことがある。[ 15] :2
DRAM集積回路 の密度の向上は、電荷 を少ししか蓄えられない物理的に小さなメモリセルをもたらし、結果として動作のノイズマージン (英語版 ) は減少し、メモリセル相互間の電磁相互作用の度合いが増大し、データ損失の可能性が上昇した。
結果として外乱エラー (disturbance error) が観測された。それはメモリセルが相互の動作を妨害することにより、影響されたメモリセルに格納されたビットの値がランダムに変化することで明らかとなった。
外乱エラーについての指摘は1970年代初期にさかのぼる。初の商業的DRAM集積回路 (IC)・インテル1103以来、メモリセル間の絶縁性向上、製品検査の実施など、DRAMメーカーは種々の技術で外乱エラーを軽減 してきた。
しかし研究者は2014年に、2012年・2013年に製造された商用のDDR3 SDRAM チップが外乱エラーの影響を受けることを確かめた。その中で、観測されたビット反転 を導く副作用をロウハンマー (row hammer) と命名している
[ 1] [ 3] [ 15] 。
DDR3メモリでロウハンマーが起こる機会は、高いメモリセル密度に起因するメモリセル間相互作用の結果がもたらしたとはじめは考えられていたが、高速な DRAM 行選択動作が主な原因であると究明された[ 16] 。
高速な行選択動作は対応する行選択線に電圧変動を引き起こし、近くの(ほとんどの場合、隣の)行(被害行 (victim row) と呼ばれる)にあるキャパシタに自然状態よりも高い放電率を誘発するのが観測された。影響されたメモリセルが電荷を一定以上失ってもリフレッシュ されないとき、外乱エラーが起こる。
テストでは(キャッシュ のフラッシュ とともに)約139,000回のメモリ行アクセスを続けると外乱エラーが観測される可能性があり、影響を受けるメモリセルが1,700個のうち1個にのぼる恐れがあることが示されている。
また、これらのテストは外乱エラーの頻度は環境温度の上昇には実質的に影響されず、DRAMの記憶内容に依存することを示している。特定のビットパターンによって外乱エラーの頻度が大幅に高まるのである[ 1] [ 2] [ 15] [ 17] 。
両側干渉 (double-sided hammering) と呼ばれるバリエーションは、被害行を取り巻く2つの行を動作させるものである。この節のイラストでは、紫色の被害行にビット反転を誘発するねらいで両方の黄色の行を動作させる。
テストでは、この方法により被害行の片側の隣接行だけを動作させる場合に比べて外乱エラーの頻度が大きく上昇する可能性があることを示している
[ 4] [ 18] :19–20 [ 19] 。
ロウハンマーの検出・予防・修正・緩和には様々な手法が存在し、効果もそれぞれである。
テストによると、単純なECC による対策は、1ビットのエラー修正と2ビットのエラー検出能力を持つが、メモリの1ワード に3つ以上のビット反転が起きることがあり、外乱エラーのすべてを修正あるいは検出できないことを示している。
[ 1] :8
[ 15] :32
より効果的な対策は、通常の 64ms間隔よりも頻繁にリフレッシュ を行うことである。
[ 注釈 1]
しかしこの方法では消費電力と処理のオーバーヘッド が増大する。いくつかのメーカーはファームウェア の更新によってこの種の緩和策を提供している
[ 20] 。
もう少し手の込んだ方法として、カウンタ に基づいて頻繁にアクセスされる行を特定し、前もって隣接する行をリフレッシュするというものがある。別の方法として、アクセスされた行の隣接行をアクセス頻度に関係なくときどきランダムにリフレッシュするというものもある。
研究は、これら2つの予防策の性能への影響は無視できる程度だと説明している
[ 1] :10–11 [ 21] 。
Ivy Bridgeマイクロアーキテクチャ のリリース以後、インテル Xeon プロセッサは疑似目標行リフレッシュ (pseudo target row refresh, pTRR ) と呼ばれるものをサポートしている。pTRR対応DDR3 DIMM はロウハンマー効果を緩和するように被害行となりそうな行を自動的にリフレッシュし、メモリ性能や消費電力にほとんど影響を与えない。
pTRR非対応のDIMMが使われた場合、デフォルトでこれらのXeonプロセッサはDRAMのリフレッシュ頻度を通常の2倍にする。結果として、メモリアクセスのレイテンシ が少し増え、メモリの帯域幅 が最大2〜4%減少する
[ 9] 。
JEDEC の発行したLPDDR4 モバイルメモリ 規格には
[ 22] 、
オプション回路として目標行リフレッシュ (target row refresh, TRR ) と呼ばれるもののサポートが含まれている。これは性能や消費電力にほとんど影響を与えずにロウハンマー効果を予防する
[ 10] [ 23] [ 24] 。
さらに、JEDECの発行したDDR4メモリ規格には含まれていないにもかかわらず、一部のメーカーはDDR4製品にTRRを実装している
[ 25] [ 26]
[ 27] 。
内部的にTRRは行選択動作の数を数え、あらかじめ決められたチップ 固有の最大動作数 (maximum activate count, MAC)・最大動作時間 (maximum activate window, tMAW ) の値と比較することで、被害行となりそうな行を特定し、これらの行をリフレッシュしてビット反転を予防する。
MAC 値は、DRAM の特定の行が、その隣接行が被害行と認識されるまでの時間 tMAW と同じかそれ以下の一定時間間隔のうちに遭遇しうる行選択動作の合計数の最大値である。TRR はまた、タイミング・ウインドウ tMAW のうちに2つの隣接行の行選択動作の合計が MAC の制限に達したとき、被害行としてフラグ を立てる
[ 22] [ 28] 。
ロウハンマーの悪用は、高速なDRAM行選択動作を膨大な数で行う必要があるため多数のキャッシュされないメモリアクセスを行いキャッシュミス を引き起こすので、
ハードウェアパフォーマンスカウンタ (英語版 ) を使ってキャッシュミス発生率をモニターすることで異常なピークとして検出できる
[ 4] [ 29] 。
2013年12月3日にリリースされたメモリ診断ソフトMemtest86 Version 5.0 には、コンピューターのRAM が外乱エラーに影響されるかどうかを検査するロウハンマーテスト が追加された。これはUEFI ブート のコンピュータでしか機能しない。UEFIのないコンピュータではロウハンマーテストのない古いバージョンが起動する
[ 30] 。
プロセス に割り当て られていないメモリへのアクセスを防止するメモリ保護 は、最新のオペレーティングシステム の背後にある概念の1つである。
プログラム (や一般にコンピュータシステム )は特定のタスク を実行するために要求される限られた権限 を持つ各部分であるプロセスに分割されるが、リングプロテクション など他のセキュリティ機構とメモリ保護を組み合わせることで、プロセス間の特権分離 (英語版 ) が達成できる。
特権分離を使うと、コンピュータセキュリティ に対する攻撃の効果をシステムの特定の部分に制限することにより、潜在的な被害の範囲を小さくすることもできる
[ 31] [ 32] 。
外乱エラー(→#概要 )は、基盤にあるメモリのハードウェアを直接操作するユニークな攻撃経路 (英語版 ) を実質的に作ることで、プロセスがメインメモリ の任意の部分を変更できるようになり、メモリ保護のさまざまな層をとても低いハードウェアレベルで「短絡する」ことにより効果的に打ち破ってしまう
[ 2] [ 4] [ 18] [ 33] 。
これと比較して、バッファオーバーフロー のような「従来の」攻撃経路は、プログラムのさまざまなミスを悪用 して保護機構をソフトウェアのレベルで迂回し、他の方法ではアクセスできないメインメモリの内容を変更することを狙っている
[ 34] 。
code1a:
mov ( X ), %eax // read from address X
mov ( Y ), %ebx // read from address Y
clflush ( X ) // flush cache for address X
clflush ( Y ) // flush cache for address Y
mfence
jmp code1a
ロウハンマーを誘発する x86-64 アセンブリ コードの一部。メモリアドレス X と Y は同じメモリバンク 上のDRAMの異なる行に置く必要がある。[ 1] :3 [ 4] [ 18] :13–15
ロウハンマーに関する最初の研究は2014年6月に出版され、外乱エラーの性質と潜在的な攻撃方法を示していたが、実際に動作する攻撃例は
載っていなかった
[ 1] 。
続く2014年10月の研究論文では、ロウハンマー効果に起因するセキュリティ問題の存在に触れていなかった
[ 16] 。
2015年3月9日、Google のProject Zero (英語版 ) はロウハンマー効果に基づく実際に動作する特権昇格 (英語版 ) の2つの悪用例を明らかにし、x86-64 アーキテクチャ における脆弱性を実証した。
ひとつはサンドボックスでx86-64 機械語命令 の制限されたサブセットを実行する Google Native Client (NaCl) 機構を標的にしたもので、ロウハンマー効果を悪用してサンドボックス から脱出し、システムコール を直接発行する可能性を増大させている。
[ 18]
この NaCl の脆弱性 (CVE -2015-0565 )は、効果的なロウハンマー攻撃を組み立てるために必要だと以前は考えられていた clflush機械語命令(キャッシュライン をフラッシュ する)
[ 35] )
を許さないように NaCl を修正することで緩和された
[ 2] [ 4] [ 33] 。
2つめはx86-64アーキテクチャ 上のLinux の特権 を持たないプロセス として実行され、コンピュータに実装されているすべての物理メモリ に制限なくアクセスするためにロウハンマー効果を悪用した。外乱エラーとヒープスプレー (英語版 ) を組み合わせることで、この悪用例では
仮想メモリ システムで仮想アドレス と物理アドレス のマッピング に使われるページテーブル エントリー (page table entry, PTE)
[ 18] :35
の変更を可能にしており、結果として制限のないメモリアクセスが可能になっている
[ 18] :34,36–57 。
その性質と、clflush を特権命令 にできない x86-64 アーキテクチャのため、ロウハンマーを回避する組み込みハードウェア機構を使わないコンピュータではこの脆弱性の緩和が困難である。
脆弱性のテストにおいて、Project Zero はテストした29のノートパソコン の約半数で外乱エラーが発生することを見出した。いくつかの脆弱なノートパソコンではロウハンマーを導入するコードを実行して5分以内に発生した。テストに用いられたのは、2010年から2014年に製造され、非 ECC の DDR3 メモリを使用したノートパソコンだった
[ 2] [ 4] [ 33] 。
2015年7月、セキュリティ研究者のグループはアーキテクチャ と命令セット に依存しないロウハンマーの悪用方法についての論文を出した。
この方法ではキャッシュのフラッシュを実行するclflush命令を使う代わりに、注意深く選ばれたメモリアクセスパターンを使って非常に高い率でキャッシュ の破棄を引き起こすことによりキャッシュされていないメモリアクセスを実現する。
キャッシュ置換ポリシー はプロセッサによって異なるが、このアプローチは適応型キャッシュ破棄戦略アルゴリズム を採用することによってアーキテクチャの違いを克服している
[ 18] :64–68 。
このアプローチの概念実証 は、機械語による実装と Firefox 39 上で実行される純粋な JavaScript による実装の両方によって与えられた。
Rowhammer.js と呼ばれる JavaScript による実装は
[ 36] 、
大きな型付き 配列 を使い、内部で大きなページ を割り当て られることに依存している。
結果として、非常に低いレベルの脆弱性による非常に高いレベルの悪用を実証している
[ 37] [ 38] [ 39] [ 40] 。
2016年10月、VUSec Systems の研究者とVU Amsterdam のネットワークセキュリティグルーブはDRAMMER というAndroidアプリを発表した。これはロウハンマーと他の方法を使って、いくつかの有名なモデルのスマートフォンで確実に特権を獲得する
[ 41] 。
この脆弱性はCVE -2016-6728 として知られており
[ 42] 、
影響を軽減するパッチ が1か月以内にGoogleからリリースされたが、攻撃の可能な実装の一般的な性質上、効果的なソフトウェアパッチを確実に実装することは難しい。
事実、2018年6月までに研究機関と産業界から出されたほとんどの提案は実施が難しいか、すべての攻撃を止めるには不十分なものだった
[ 43] 。
これらの攻撃を軽減するために、VUSec Systemsの研究者はDMAバッファ を防護行で隔離することでDMA ベースの攻撃を予防する軽量な防御策を提案した
[ 43] [ 44] 。
ソフトウェアのすべての状態がロウハンマーに対して脆弱であるわけではない。ゆえに攻撃者はロウハンマーによるエラーを利用するために目標の正しい状態を見つける必要がある。実際的には、目標の状態を特定することが主な課題の1つとなる。それは通常、ドメイン [要曖昧さ回避 ] の専門家が行う。The mainstream fault tolerance community はロウハンマー攻撃に対して、目標の状態とその悪用可能性を特定し、確認し、評価できる体系的な方法で対応した
[ 45] 。
この仕事は欠陥の導入を基礎とする十分に確立された経験的な方法論と一般的な攻撃目標の状態に基づいており、それまで知られていなかった実際的な目標の状態をいくつか発見した。
w:en:Memory scrambling – memory controller feature that turns user data written to the memory into pseudo-random patterns
w:en:Radiation hardening – the act of making electronic components resistant to damage or malfunctions caused by ionizing radiation
w:en:Single event upset (SEU) – a change of state caused by ions or electromagnetic radiation striking a sensitive node in an electronic device
w:en:Soft error – a type of error involving erroneous changes to signals or data but no changes to the underlying device or circuit
^ a b c d e f g h “Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors ” (PDF). ece.cmu.edu . IEEE (June 24, 2014). March 10, 2015 閲覧。
^ a b c d e f Dan Goodin (March 10, 2015). “Cutting-edge hack gives super user status by exploiting DRAM weakness ”. Ars Technica . March 10, 2015 閲覧。
^ a b Paul Ducklin (March 12, 2015). “'Row hammering' – how to exploit a computer by overworking its memory ”. Sophos . March 14, 2015 閲覧。
^ a b c d e f g “Exploiting the DRAM rowhammer bug to gain kernel privileges ”. googleprojectzero.blogspot.com . Google (March 9, 2015). March 10, 2015 閲覧。
^ “Using Rowhammer bitflips to root Android phones is now a thing” . Ars Technica . https://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-root-android-phones-is-now-a-thing/ 2016年10月25日 閲覧。
^ Khandelwal, Swati (2018年5月3日). “GLitch: New 'Rowhammer' Attack Can Remotely Hijack Android Phones” . The Hacker News . https://thehackernews.com/2018/05/rowhammer-android-hacking.html 2018年5月21日 閲覧。
^ Kumar, Mohit (2018年5月10日). “New Rowhammer Attack Can Hijack Computers Remotely Over the Network” . The Hacker News . https://thehackernews.com/2018/05/rowhammer-attack-exploit.html 2018年5月21日 閲覧。
^ Khandelwal, Swati (2018年5月16日). “Nethammer—Exploiting DRAM Rowhammer Bug Through Network Requests” . The Hacker News . https://thehackernews.com/2018/05/remote-rowhammer-attack.html 2018年5月21日 閲覧。
^ a b Marcin Kaczmarski (August 2014). “Thoughts on Intel Xeon E5-2600 v2 Product Family Performance Optimisation – Component selection guidelines ” (PDF). インテル . p. 13. March 11, 2015 閲覧。
^ a b Marc Greenberg (October 15, 2014). “Reliability, Availability, and Serviceability (RAS) for DDR DRAM interfaces ” (PDF). memcon.com . pp. 2, 7, 10, 20, 27. March 11, 2015 閲覧。
^ a b “Lecture 12: DRAM Basics ” (PDF). utah.edu . pp. 2–7 (February 17, 2011). March 10, 2015 閲覧。
^ a b “Understanding DRAM Operation ”. IBM (December 1996). March 10, 2015 閲覧。
^ David August (November 23, 2004). “Lecture 20: Memory Technology ” (PDF). cs.princeton.edu . pp. 3–5. May 19, 2005時点のオリジナル よりアーカイブ。March 10, 2015 閲覧。
^ “DRAM Errors in the Wild: A Large-Scale Field Study ” (PDF). cs.toronto.edu . ACM (June 25, 2009). March 10, 2015 閲覧。
^ a b c d e “Flipping Bits in Memory Without Accessing Them: DRAM Disturbance Errors ” (PDF). ece.cmu.edu (June 24, 2014). March 10, 2015 閲覧。
^ a b “Active-Precharge Hammering on a Row Induced Failure in DDR3 SDRAMs under 3x nm Technology ”. IEEE (October 2014). doi :10.1109/IIRW.2014.7049516 . March 16, 2015 閲覧。
^ “RowHammer: Reliability Analysis and Security Implications ” (PDF). ece.cmu.edu (July 30, 2015). August 7, 2015 閲覧。
^ a b c d e f g “Exploiting the DRAM rowhammer bug to gain kernel privileges: How to cause and exploit single bit errors ” (PDF). Black Hat (August 6, 2015). August 7, 2015 閲覧。
^ Andy Greenberg (March 10, 2015). “Googlers' Epic Hack Exploits How Memory Leaks Electricity ”. Wired . March 17, 2015 閲覧。
^ “Row Hammer Privilege Escalation (Lenovo Security Advisory LEN-2015-009) ”. レノボ (August 5, 2015). August 6, 2015 閲覧。
^ “Architectural Support for Mitigating Row Hammering in DRAM Memories ” (PDF). ece.gatech.edu . IEEE (October 9, 2014). March 11, 2015時点のオリジナル よりアーカイブ。March 11, 2015 閲覧。
^ a b “JEDEC standard JESD209-4A: Low Power Double Data Rate (LPDDR4) ” (PDF). JEDEC . pp. 222–223 (November 2015). January 10, 2016 閲覧。
^ Kishore Kasamsetty (October 22, 2014). “DRAM scaling challenges and solutions in LPDDR4 context ” (PDF). memcon.com . p. 11. January 10, 2016 閲覧。
^ Omar Santos (March 9, 2015). “Mitigations Available for the DRAM Row Hammer Vulnerability ”. cisco.com . March 11, 2015 閲覧。
^ Marc Greenber (March 9, 2015). “Row Hammering: What it is, and how hackers could use it to gain access to your system ”. synopsys.com . January 10, 2016 閲覧。
^ Jung-Bae Lee (November 7, 2014). “Green Memory Solution (Samsung Investors Forum 2014) ” (PDF). teletogether.com . Samsung Electronics . p. 15. January 10, 2016 閲覧。
^ “JEDEC standard JESD79-4A: DDR4 SDRAM ” (PDF). JEDEC (November 2013). January 10, 2016 閲覧。
^ “Data Sheet: 4 Gb ×4, ×8 and ×16 DDR4 SDRAM Features ” (PDF). マイクロン・テクノロジ . pp. 48, 131 (November 20, 2015). January 10, 2016 閲覧。
^ “These are Not Your Grand Daddy's CPU Performance Counters: CPU Hardware Performance Counters for Security ” (PDF). Black Hat . pp. 29, 38–68 (August 6, 2015). January 9, 2016 閲覧。
^ “PassMark MemTest86 – Version History ”. memtest86.com (February 13, 2015). March 11, 2015 閲覧。
^ Pehr Söderman (2011年). “Memory Protection ” (PDF). csc.kth.se . March 11, 2015 閲覧。
^ “Preventing Privilege Escalation ” (PDF). niels.xtdnet.nl (August 10, 2003). March 11, 2015 閲覧。
^ a b c Liam Tung (March 10, 2015). “"Rowhammer" DRAM flaw could be widespread, says Google ”. ZDNet . March 11, 2015 閲覧。
^ Murat Balaban (June 6, 2009). “Buffer Overflows Demystified ” (TXT). enderunix.org . March 11, 2015 閲覧。
^ “CLFLUSH: Flush Cache Line (x86 Instruction Set Reference) ”. renejeschke.de (March 3, 2013). August 6, 2015 閲覧。
^ “IAIK/rowhammerjs: rowhammerjs/rowhammer.js at master ”. github.com (July 27, 2015). July 29, 2015 閲覧。
^ Gruss, Daniel; Maurice, Clémentine; Mangard, Stefan (24 July 2015). "Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript". arXiv :1507.06955 [cs.CR ]。
^ David Auerbach (July 28, 2015). “Rowhammer security exploit: Why a new security attack is truly terrifying ”. slate.com . July 29, 2015 閲覧。
^ Jean-Pharuns, Alix (2015年7月30日). “Rowhammer.js Is the Most Ingenious Hack I've Ever Seen” . Motherboard. https://motherboard.vice.com/en_us/article/9akpwz/rowhammerjs-is-the-most-ingenious-hack-ive-ever-seen
^ Goodin, Dan (2015年8月4日). “DRAM 'Bitflipping' exploit for attacking PCs: Just add JavaScript” . Ars Technica. https://arstechnica.com/information-technology/2015/08/dram-bitflipping-exploit-for-attacking-pcs-just-add-javascript/
^ VUSec (October 2016). “DRAMMER: FLIP FENG SHUI GOES MOBILE ”. January 21, 2017 閲覧。
^ NIST National Vulnerability Database (NVD). “CVE-2016-6728 Detail ”. 2018年9月9日 閲覧。
^ a b van der Veen, Victor; Lindorfer, Martina; Fratantonio, Yanick; Padmanabha Pillai, Harikrishnan; Vigna, Giovanni; Kruegel, Christopher; Bos, Herbert; Razavi, Kaveh (2018), “GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM” (英語), Detection of Intrusions and Malware, and Vulnerability Assessment (Springer International Publishing): pp. 92–113, doi :10.1007/978-3-319-93411-2_5 , ISBN 9783319934105 , http://link.springer.com/10.1007/978-3-319-93411-2_5 2018年6月30日 閲覧。
^ “RAMPAGE AND GUARDION - Vulnerabilities in modern phones enable unauthorized access ”. June 30, 2018 閲覧。
^ Keun Soo Yim (2016年). “The rowhammer attack injection methodology ”. 2018年9月9日 閲覧。 [リンク切れ ]
Some notes on DRAM (#rowhammer) , March 9, 2015, by Robert Graham
Rowhammer hardware bug threatens to smash notebook security , InfoWorld , March 9, 2015, by Serdar Yegulalp
DDR3 Memory Known Failure Mechanism called "Row Hammer" - YouTube , July 17, 2014, by Barbara Aichinger
Patent US 20140059287 A1: Row hammer refresh command , February 27, 2014, by Kuljit Bains et al.
Row Hammer Privilege Escalation Vulnerability , Cisco Systems security advisory, March 11, 2015
ARMOR: A run-time memory hot-row detector , The University of Manchester , by Mohsen Ghasempour et al.
Using Memory Errors to Attack a Virtual Machine , March 6, 2003, by Sudhakar Govindavajhala and Andrew W. Appel
A program for testing for the DRAM "rowhammer" problem , source code on GitHub
RAMBleed: Reading Bits in Memory Without Accessing Them # RowHammer は物理メモリ上で隣接するデータを破壊する攻撃であるが,RAMBleed はデータを盗む攻撃である。