全員に対するRowhammer禁止措置、すべてソフトウェアで

Table of Contents

全員に対するRowhammer禁止措置、すべてソフトウェアで

ドイツの研究者グループは、すべての x86 アーキテクチャを「Rowhammer」メモリバグから保護する方法という非常に難しい問題を解決したと考えています。

「Rowhammer」が初めて出現してから 18 か月が経過し、対応策としては主に、自社の環境で「ビットフリッピング」攻撃をブロックする方法を模索している個々のベンダーからのものとなっています。

LWN は昨年 10 月、Linux カーネルの専門家たちが Linux の環境で機能する汎用防御に取り組んでいると報じましたが、x86 の世界全体を保護できればさらに良いでしょう。

これが、この ArXiv 論文の著者が主張していることです。つまり、異なるシステム エンティティ (たとえば、カーネル) のメモリをユーザー空間から分離する、x86 および ARM マシン用のソフトウェアのみの防御です。

研究者らはドイツのダルムシュタット工科大学とデュースブルク=エッセン大学の出身者である。

保護を理解するには、Rowhammer リフレッシュが役立つでしょう。なぜなら、DRAM に破損を強制できれば、理論的にはカーネルを乗っ取る方法を見つけることができるからです。

理論を概念実証に変えたのはGoogleのProject Zeroであり、The RegisterのIain Thomsonは当時次のように報じている。

「『ロウハンマー』と呼ばれるこの手法は、メモリへの高速な書き込みと書き換えによってDRAMのコンデンサにエラーを発生させ、これを悪用してシステムを制御することができます。RAMセルの1つのラインを繰り返し充電することで、隣接するラインのビットが変更され、保存されているデータが破壊される可能性があります。」

「この破損により、誤った命令が実行されたり、プログラムへのメモリの割り当て方法を制御する制御構造が変更されたりする可能性があります。後者の場合、通常のプログラムがカーネルレベルの権限を取得するために利用される可能性があります。」

物理 RAM にアクセスできるようになると、Project Zero の攻撃者はメモリ保護とセキュリティ メカニズムを回避し、オペレーティング システムの構造を改ざんしてマシンを乗っ取ることができるようになります。

新しい論文の著者らが書いているように、Rowhammer に対する防御策のほとんどは、ハードウェアを変更するか、CPU に対してヒューリスティック ベースのカウンターを実行して警告を発するものでした。

Duisburg-Essen グループは異なるアプローチを採用しました。同グループの G-CATT (Generic CAn't Touch This) は x86 専用の B-CATT (Bootloader CAn't Touch This) 上に構築されており、脆弱な物理メモリを無効にするためにブートローダを拡張しています。

しかし、ブートローダのアプローチは Rowhammer 特有のものでした。「物理メモリにおけるメモリ分離の欠如という根本的な問題にはまだ対処していない」ため、研究者たちはそれを「汎用的」にするために研究を拡張しました。

G-CATT は異なる角度からアプローチします。メモリを分離するのではなく、攻撃者がすでに制御下にあるメモリ内のビットのみを反転できるようにすることで、攻撃者がその効果を悪用するのを阻止し、Rowhammer を無効化します。

この制限は「Rowhammer によって引き起こされるビット反転を許容しますが、ビット反転がより高い権限を持つセキュリティ ドメイン (OS カーネルや共存する仮想マシンなど) に属するメモリに影響するのを防ぎます」。「そのために、G-CATT は物理メモリ アロケータを拡張して、物理メモリをセキュリティ ドメインに分割します。」

B-CATTとG-CATTのブロック図

B-CATTとG-CATTのブロック図

防御によってシステムが使用不能になっては意味がないので、研究者らは保護されたマシン上で一連のベンチマークも実行しました (Linux で B-CATT と G-CATT の両方を使用)。

SPEC2006 (さまざまなプログラムのパフォーマンスをテストする) では、B-CATT のパフォーマンス低下は平均 0.43 パーセント、G-CATT のパフォーマンス低下は平均 0.49 パーセントでした。

Phoronix ベンチマークのパフォーマンスはより優れており、B-CATT では 0.19% 遅くなり、G-CATT では 0.33% 遅くなりました。

2 つのシステムはファイルおよび VM レイテンシ テストで良好に動作し、2 つの保護スキームはローカル帯域幅とメモリ レイテンシに最小限の影響しか与えませんでした。®

Discover More