[論文レビュー] SafeSpec: Banishing the Spectre of a Meltdown with Leakage-Free Speculation

Khaled N. Khasawneh, Esmaeil Mohammadian Koruyeh+4 more|arXiv (Cornell University)|Jun 13, 2018

Security and Verification in Computing被引用数 41

ひとこと要約

SafeSpec は、推測状態を影の構造に置くことで漏えいのない推測実行を実現し、コミット時にのみそれをコミット状態へ移動させることで Spectre/Meltdown の漏えいを防ぎつつ性能を維持します。2つのコミット変種（WFC および WFB）を分析し、過渡的な推測攻撃を特定し、性能への影響がほとんどないハードウェアプロトタイプを示します。

ABSTRACT

Speculative execution which is used pervasively in modern CPUs can leave side effects in the processor caches and other structures even when the speculated instructions do not commit and their direct effect is not visible. The recent Meltdown and Spectre attacks have shown that this behavior can be exploited to expose privileged information to an unprivileged attacker. In particular, the attack forces the speculative execution of a code gadget that will carry out the illegal read, which eventually gets squashed, but which leaves a side-channel trail that can be used by the attacker to infer the value. Several attack variations are possible, allowing arbitrary exposure of the full kernel memory to an unprivileged attacker. In this paper, we introduce a new model (SafeSpec) for supporting speculation in a way that is immune to side-channel leakage necessary for attacks such as Meltdown and Spectre. In particular, SafeSpec stores side effects of speculation in a way that is not visible to the attacker while the instructions are speculative. The speculative state is then either committed to the main CPU structures if the branch commits, or squashed if it does not, making all direct side effects of speculative code invisible. The solution must also address the possibility of a covert channel from speculative instructions to committed instructions before these instructions are committed. We show that SafeSpec prevents all three variants of Spectre and Meltdown, as well as new variants that we introduce. We also develop a cycle accurate model of modified design of an x86-64 processor and show that the performance impact is negligible. We build prototypes of the hardware support in a hardware description language to show that the additional overhead is small. We believe that SafeSpec completely closes this class of attacks, and that it is practical to implement.

研究の動機と目的

• 現代のCPU全体における推測実行（Spectre/Meltdown）に由来するセキュリティ脆弱性を動機づけ、対処する。
• 推測を一時的な構造に分離して漏えいを防ぐよう、原理的設計（SafeSpec）を提案する。
• Known な推測変種と新規な推測変種に対する SafeSpec のセキュリティを評価し、性能/複雑さのトレードオフを評価する。
• キャッシュとTLBに対する具体的な SafeSpec 実装を実演し、ハードウェア資源および潜在的な covert channel への影響を分析する。

提案手法

• 推測効果を従属状態から切り離して保持する影の（暫定的）状態という SafeSpec の原則を導入する。
• wait-for-commit (WFC) および wait-for-branch (WFB) の2つのコミットモデルを説明し、それらのセキュリティ影響（Meltdown と Spectre）とトレードオフを分析する。
• データキャッシュ、i-cache、TLB を含むメモリ階層を影の構造で拡張し、推測データを保持し、コミット状態へ移動するかスプッシュ（抑制）するかのポリシーを定義する。
• Transient Speculation Attacks (TSA) に対処するため、推測ウィンドウと影の状態設計を規模化・分割して covert channels を防ぐ。
• シャドウキャッシュ、シャドウ iTLB/dTLB、ROB および Load/Store キューとの統合を含むキャッシュおよび TLB の SafeSpec 設計をプロトタイプ化する。
• 性能と複雑さを評価するためのサイクル正確なモデルを提供し、実用的なハードウェアオーバーヘッドについて議論する。）

実験結果

リサーチクエスチョン

• RQ1 推測実行は性能を損なうことなく漏えいをなくせるのか？
• RQ2 推測状態はどのように整理され、Meltdown/Spectre および TSA を防ぐためにいつコミット状態へ移動すべきか？
• RQ3 SafeSpec がキャッシュ、TLB、I-cache の漏えい、性能、およびハードウェアオーバーヘッドに与える影響は？
• RQ4 WFC および WFB の変種は既知の推測攻撃や新たに導入された攻撃を効果的に止められるのか？
• RQ5 SafeSpec を広く適用する際の実用的な制限事項と今後の課題は何か（マルチコア、プリフェッチ、コヒーレンス）？

主な発見

• SafeSpec は影の状態を推測データに使用し、コミット時にのみコミット状態へ移動する（WFC）またはブランチがコミットされてから移動する（WFB）ことで既知の Meltdown および Spectre の変種を防ぐ。
• キャッシュおよびTLB のための影の構造のサイズ設定は実現可能で、性能影響はほとんどなく、場合によっては実効キャッシュサイズの増加により控えめな改善をもたらすことがある。
• TSA（Transient Speculation Attacks）は、推測ウィンドウと影の状態設計を守ることによって、推測指示とコミット指示の間の covert channels を防ぎ、対処される。
• SafeSpec によるメモリ階層の拡張は面積と電力のオーバーヘッドを許容範囲に保ちつつ、推測の利点を維持し、キャッシュ汚染を低減する。
• サイクル正確なモデルとハードウェアプロトタイプは、このアプローチが現実的で、過度な性能ペナルティを課さないことを示している。