確認できた範囲の情報を記録しておこうと思います。
Rowhammer問題
最近のメモリで見られる 同じ行に連続してアクセスすると直接アクセスしていない領域の値が化ける現象(RowHammer問題) を利用してLinuxで権限昇格ができる模様 http://t.co/10kwCTzMyJ
— Fadis (@fadis_) 2015, 3月 10
PC Watchの記事「DRAMスケーリングの課題と打開策」にて解説がなされています。以下当該記事より引用:
Row Hammer問題は、DRAM技術が微細化したことで深刻になり始めたメモリセル間の干渉によって発生するエラーの問題だ。 DRAMメモリセルの同じRow(行)に対する連続したアクセスが、隣接したRowのセルのデータを不安定し、エラーを生じさせる。この問題は2012年頃から話題になり始めた。Intelはメモリ制御に関する特許(Row hammer condition monitoring, US 20140006704 A1など)の中で言及した。そして、今年(2014年)6月のコンピュータアーキテクチャ学会「ISCA (International Symposium on Computer Architecture)」でRow Hammerに関する論文が発表されたことで、コンピュータ業界で広く知られるようになった。
ハードウェアについてあまり詳しくないのですが、高密度化、高速化したメモリで、特定のセル(row)に高い頻度でアクセスすると隣接するrowのメモリ内容が化ける、という現象のようです(Rowhammerの論文PDF)。
攻撃への応用
Googleのセキュリティ対策チーム”Project Zero”が、この現象を応用して攻撃に利用する、という記事を公開しました(“Exploiting the DRAM rowhammer bug to gain kernel privileges“)。応用例として、ChromeのNaClサンドボックス上で本来実行できないはずの命令を実行させたり、カーネルの権限上昇を行う手法が解説されています。
確認手段
userlandで試験を行うツールがgithubで公開されています(“https://github.com/google/rowhammer-test“)。また、memtest86 6.0.0 Free editionにもRowhammerテスト機能が追加されているようです。 rowhammer_testを実行して、実際にエラーが起きると以下のような出力をして停止します。
Iteration 11 (after 16.41s) 32.448 nanosec per iteration: 1.40176 sec for 43200000 iterations check error at 0x7f032bcde188: got 0xffffffffffdfffff (check took 0.122344s) ** exited with status 256 (0x100)
自分はデスクトップ(non-ECC)x2、ノート(non-ECC)x1、サーバー(ECC)x1に対して実施してみましたが、以前から挙動が若干怪しげなデスクトップマシン1台でのみ検出されました。 Google Groupsにてある程度報告が上がってきていますが、発生するときは数十～数百程度の試行回数で発生するようです(上記自分の例では11回目で発生)。自分の他のマシンでは1万以上行っても問題が出ませんでした。 自分はVirtualBox環境下でこのテストに引っかかったのですが、GroupsではXen guest上でエラーを検出できたという報告もありました。Cygwinでも確認できるよそうです。
@knok 参考になるかはわかりませんが、原理上 Cygwin でも (double-sided でない方の) rowhammer_test は動作するようです。
— Tsukasa #01 (@a4lg) 2015, 3月 10
対処方法
2ちゃんねるソフトウェア板のMemtest86スレッドにてメモリアクセスに関するパラメータを試行錯誤している様子があります。
>スケーリングによってDRAMが直面する問題として
>「Refresh」、「Write Recovery Time (tWR)」、「Variable Retention Time (VRT)」の3つを挙げている。tREFIとtREFIx9, tRFCだけでなくtWRも関係してくるわけか・・・
BIOS等でこれらのパラメータを変える、特にリフレッシュ時間(tREFI)を短くすることで改善が見込めるようです。
ところで、ちょうど今日のタイミングで2chのdatアクセスが閉じられてしまいました(窓の杜の記事:「２ちゃんねる”の配信仕様が本日より変更。専用ブラウザーの更新・乗り換えを」)。そのままでは、Debianパッケージにもなっているnavi2chやJDなどが利用できない状態です。Memtest86スレッドのような貴重な情報を得られる場だけに残念です。
追記(2015/3/16)
マシンを再起動する機会があったので、tREFIを設定してみました。設定可能な最小値として800(usec?)に設定したところ、iteratin 3000を超えて問題なくテストが進んでいます(当該マシンのデフォルト値は1700ぐらい)。前回は11回でエラーが発生したことを考えると、かなり改善されているようです。割と思い処理(動画エンコード)を差せているのですが、それほど目立った性能低下も感じられません。
