Hisa Ando氏のブログで知ったのだが、Spectre & Meltdownを防ぐマイクロアーキテクチャとしてSafeSpecという技術が発表されたので、これを読んでみることにした。
Boffins offer to make speculative execution great again with Spectre-Meltdown CPU fix www.theregister.co.uk
Meltdown/Spectreの対策 SafeSpec keisanki.at.webry.info
論文 「SafeSpec: Banishing the Spectre of a Meltdown with Leakage-Free Speculation」
https://arxiv.org/pdf/1806.05179.pdf
Hisa Ando氏の記事にも書いてある通り、SafeSpecでは投機的実行の副作用を削減するために、Shadowキャッシュを設けている。 今回はL1Dキャッシュ、L1Iキャッシュ、TLBキャッシュに対してShadowキャッシュを適用して、投機的実行が最終的に完了するまで、完了前の投機実行の命令結果を格納しておき、投機実行が完了すると命令結果を実キャッシュに書き込む。
下記の図において、各キャッシュの横にShadowキャッシュを置き、実キャッシュが投機実行により汚れてしまうことを防いでる。
ここでおそらく誰もが想像するのが、このShadowキャッシュが汚れてしまったことによる副作用によりSpectre攻撃が起こされるのではないか？ということ。 その問題について言及しているのが、おそらく本文中に入っている"Transient Speculative Attack"という問題だと思う(あってるかな？)。
(これ、日本語の資料をあさっても、「さらに発見された脆弱性」としているけど、そりゃキャッシュをさらに追加したんだから発生するのは当然だろう... 別に彼らが新しく発見した脆弱性でも何でもない)。
この追加されたShadow キャッシュ、問題はどれくらいの大きさであるかというところである。 もしこれが小さいと、ShadowキャッシュがFullになったことにより発生するストールなどを観測すれば再びSpectreのような攻撃化可能になることが考えられる。十分に大きくすることが求められるが、そうすると面積としてオーバヘッドがある。
彼らの論文によると、命令キャッシュについては25ライン、i-TLBについては10ライン以下、d-TLBについては25ライン以下となっている。さらにグラフを見るとDキャッシュについては最大で60エントリ超が必要だとしている。 結構な面積が必要だと思うがどうだろう...
ついでに言うと、これはベンチマークプログラムを使ったことによる解析なので参考にはならないと思う。
攻撃プログラムというのはベンチマークプログラムのような特性ではないのだし、特殊な特性を持つプログラムに対してもこの防御手段が有効かどうかを考える必要がある。 これは論文をざっくり読んだ感じだとNoではないのだろうか。
検証方法については、サイクルベースのシミュレータを改造することにより実現している。 MARSSx86と呼ぶ。これは初めて知った。
こういうのすごく面白いと思う。マイクロアーキテクチャの研究にはこういうシミュレータを使いこなすことが重要だなあ。
いずれにしろ、ざっくりと呼んだだけなので、もう少し深く読み進めていきたい。
