MICRO 51 - 最優秀論文はLLC経由の情報リーク防止技術が受賞

福岡で開催されたMICRO 51で、最優秀論文賞を獲得したのは、ジョージア工科大学のMoinunddin Qureshi氏の「CEASER: Mitigating Conflict-Based Attacks via Encrypted-Address and Remapping」と題する論文である。

プログラム共同チェアのHyesoon Kimジョージア工科大准教授から最優秀論文賞を受け取るMoinunddin Qureshi氏

マルチコアプロセサでは、最終レベルのキャッシュ(LLC:Last Level Cache)は全コアで共有するのが一般的である。しかし、共有のキャッシュであるので、1つのコアの動作がLLC経由で、性能の点で他のコアの動作に影響するということが起こる。

次の図のように、キャッシュが2wayの場合、攻撃コアはAとBという同一セットの2つのキャッシュラインを使ってしまう。この状態で、犠牲コアが同じセットのVと書かれたキャッシュラインへ書き込みを行おうとすると、Bがキャッシュから追い出される。

この後で攻撃者がAとBにアクセスしようとすると、Bは追い出されていてキャッシュには存在せずメインメモリから読まれるので、Bへのアクセスには長い時間が掛かる。このため、攻撃コアは犠牲コアがBが入っていたキャッシュラインにアクセスしたことを知ることができる。だからどうなるのという気もするが、D. J. Bernstein氏の論文では、この攻撃でAES暗号のカギを盗み出せることが示されている。

LLCを共用する犠牲者コアのアクセスパターンを、競合的にキャッシュアクセスを行う攻撃コアが推測することが可能である

この問題に対するこれまでの解決法は、次の図の左のようにマルチウェイのキャッシュをウェイ分割してそれぞれのコアに割り当てるというものである。この方法をとれば、他のコアのキャッシュアクセスが性能的に干渉するということはほぼ無くせるが、キャッシュの使い方が非効率であり、かつ、Way数よりコア数の多いメニ―コアCPUの場合には対応ができない。

もう1つの解決法は、キャッシュをアクセスするアドレスをマッピングテーブルを使ってランダムに変更するという方法である。アドレスが変わると同じセットのアクセスを競合するものが、別々のセットにアクセスするように変わってしまい、アクセス競合による追い出しの発生の仕方がまったく変わってしまう。

どのアドレスがどのキャッシュラインに対応するかが攻撃コアにわからなければ、キャッシュのセット競合を使った攻撃は成立しない。

このキャッシュラインの位置の入れ替えを、右の図のように、マッピングテーブルを置いてランダムに対応させる方法がNewcacheなどで使われているが、容量の大きなLLCでは非常に大きなテーブルが必要になり、現実的ではない。また、マッピングテーブルを保護するためOSのサポートが必要になるなどの問題がある。

従来の解決法としてLLCをウェイ分割してコアに割り付ける方法(左)があるが、キャッシュの利用効率が悪い。また、メニ―コアCPUには対応できない。Newcacheなどではマッピングテーブルを使ってアドレスとキャッシュラインの対応をランダムにする方法がとられているが、大きなテーブルが必要になることと、テーブルを保護するためにOSのサポートが必要になるという問題がある

そこで、この研究では、以下の5つの条件を満たすコンフリクトベースの攻撃からLLCを守る方法を考えた。その条件は、以下の通りである。

記憶領域のオーバヘッドが無視できる程度であること
性能の低下が無視できる程度であること
OSのサポートを必要としないこと
キャッシュ容量の共有に制約がないこと
局所的な変更で実現できること

記憶容量や性能オーバヘッドが無視できる程度で、OSのサポートを必要とせず、実用的なコンフリクトベースの攻撃からLLCを守る方法を目指して研究を行った

まず、キャッシュを暗号化したアドレスでアクセスする方式を考えた。この方法を「Cache using Encrypted Address Space(CEASE)」と呼ぶ。次の図のように、書き込みの場合は、物理アドレスPLA(Physical Line Address)をKeyで暗号化し、暗号化されたELA(Encrypted Line Address)でLLCをアクセスする。追い出し(Evict)の場合もELAでLLCをアクセスするが、追い出されたデータはタグのELAを復号化したPLAを使ってメモリに書き戻す。

この方式では、暗号化されたELAはキャッシュの中にしか存在せず、外部からキャッシュへのアクセスは変更する必要がない。また、その都度、暗号化を行うので、Newcacheのような巨大なマッピングテーブルは必要ない。