Google のセキュリティ研究者グループは、関連するすべてのサイドチャネル攻撃を防ぐために投機実行を排除するなど、現代の CPU アーキテクチャの設計に重大な変更を加えない限り、Spectre 投機実行攻撃は今後も存在し続けるだろうと警告している。
投機的実行は有害と考えられる
Ross Mcilroy、Jaroslav Sevcik、Tobias Tebbi、Ben L. Titzer、Toon Verwaest を含むセキュリティ研究者のチームは、Google Chrome の V8 JavaScript エンジンに取り組んでおり、サイバーセキュリティ コミュニティが途中で特定の緩和策を発見したとしても、投機的実行を実行するすべてのプロセッサは常にさまざまなサイドチャネル攻撃に対して脆弱であるという結論に達しました。
1年ちょっと前、ほとんどのCPUに影響を与えるSpectreとMeltdownのバグが公表され、誰もがパニックに陥りました。これらのバグは、ハードウェアに影響を与える（つまり修正が困難である）という点だけでなく、マイクロアーキテクチャ設計全体に疑問を投げかけるという点でも、従来のものとは異なっていました。
調査レポートによると、既存および将来の Spectre バグをすべて本当に修正するには、CPU メーカーは新しい CPU マイクロアーキテクチャ設計を考案し、最新の CPU のパフォーマンスをあまり損なわず、可能であればまったく損なわないでそれを実行する必要があるとのことです。
これまでのところ、Intelは、将来のCPU世代に既知の特定のSpectreバグに対するハードウェア修正をいくつか組み込むことを約束しているだけです。しかし、問題は、Spectreバグが、サイドチャネル攻撃を可能にする投機的実行バグのクラス全体を定義しているということです。投機的実行バグを許容するマイクロアーキテクチャ設計が維持される限り、Spectreファミリーのバグは今後も発見され続けるでしょう。
攻撃者が、世界中のほとんどのデバイスに影響を及ぼし、大部分のソフトウェア保護を回避できるハードウェアのバグを悪用することに重点を置くようになると、より安全なハードウェアとプロセッサの必要性は高まるばかりです。
投機的実行とは何ですか?
投機的実行は、最新のプロセッサがパフォーマンス向上のために実装している最適化手法です。プロセッサがプログラムに必要な操作を認識する前に、特定の操作を実行することでパフォーマンスが向上します。この投機的な処理により、CPUから操作が要求されるまで待つ場合に比べて時間を節約できます。
Tom's Hardware の最高のニュースと詳細なレビューをあなたの受信箱に直接お届けします。
これは、CPU メーカーが依然として CPU から投機的実行を完全に排除することに比較的消極的であり、サイドチャネル攻撃による潜在的な被害を他の方法で軽減しようとする理由でもあります。
潜在的な緩和策
Google の研究者は、Spectre バグによって引き起こされる被害を終わらせる、または軽減するためのいくつかの緩和策を提案しました。
投機的実行を無効にする
一つ目は、投機的実行を完全に無効化することです。これにより、投機的実行に関連するあらゆる種類のバグの発生を防ぐことができます。しかし、既存のCPUのほとんどではこのオプションがユーザーに許可されておらず、許可されていたとしてもその影響範囲は非常に限られていると指摘されています。
一部の Intel CPU の LFENCE 命令は特定の種類の Spectre 攻撃を防ぐことができますが、これをすべての種類の Spectre 攻撃を防ぐために使用すると、CPU のパフォーマンスが大幅に低下する可能性があります。
タイマー緩和
もう一つの潜在的な緩和策は「タイマー緩和」と呼ばれるものです。これには、高精度タイマーの解像度を低く調整したり、タイマー自体を削除したりすることが含まれます。これは、GoogleとMozillaがブラウザに実装したSpectre対策の最初の解決策の一つでした。
しかし、Googleの研究者たちは、この緩和策にはいくつかの問題があると結論付けました。まず、特定の解像度タイマーは解像度回復に対して脆弱になる可能性があります。また、タイマーは考えられている以上に広く普及しており、高解像度タイマーは同時共有メモリから構築される可能性があります。
ブランチレスマスキング
Googleチームは、分岐予測の性質上、実行分岐を投機的実行攻撃に対する安全チェックとして用いることは回避可能であるため機能しないと指摘しました。そのため、研究者らは分岐に依存しない安全チェックを提案しました。
V8 JavaScriptエンジンの防御活動の一環として、研究チームはSpectre攻撃に対する様々なソフトウェア緩和策の開発を試みました。しかし、これらの解決策はどれも十分に包括的ではなく、深刻なパフォーマンスの低下を伴うことが分かりました。
研究者らはまた、静的および動的チェックによって強化されたプログラミング言語のセキュリティでは、同じアドレス空間内での機密性を保証できなくなったという事実にも注意を喚起した。
研究者たちは、ハードウェアとOSプロセスの分離がこれまで以上に必要だと考えています。GoogleがSpectre攻撃への対策としてブラウザにサイト分離を早期に導入したのも、MozillaがFirefoxの「Project Fission」で同様の対策を近々導入する予定なのも、おそらくこのためでしょう。
CPUベンダーへの警鐘
セキュリティ研究者は論文の最後で私たちに警鐘を鳴らし、CPU メーカーが何十年にもわたって行ってきたセキュリティとパフォーマンスのトレードオフの歴史全体に疑問を投げかけています。
私たちのモデル、私たちのメンタルモデルは間違っています。私たちはこれまでずっと、セキュリティを犠牲にしてパフォーマンスと複雑さを犠牲にしてきたにもかかわらず、それに気づいていませんでした。今日、防御にはソフトウェアによる緩和策という、さらに複雑なものが必要とされているのは、痛ましい皮肉です。そして、そのほとんどが不完全であることは周知の事実です。そして、複雑さこそが、これら3つの未解決の問題をさらに困難にしているのです。スペクターという名前は、おそらくあまりにも適切すぎるでしょう。それは、私たちを長きにわたって悩ませ続ける運命にあるように思われるからです。
