[論文レビュー] Restricting Control Flow During Speculative Execution with Venkman

Zhuojia Shen, Jie Zhou+2 more|arXiv (Cornell University)|Mar 26, 2019

Security and Verification in Computing参考文献 25被引用数 5

ひとこと要約

Venkmanは、制御転送先を固定サイズのバンドルに揃えることで、BTBおよびRSBの汚染を防ぎ、スペキュラティブ実行がフェンス命令やSFIチェックのような保護命令をスキップできないようにするソフトウェアオンリーの防御である。BTB/RSBのフラッシュや共有の制限なしに強力な緩和を実現し、SPECベンチマークで平均3.47倍のパフォーマンスオーバーヘッドを達成した。

ABSTRACT

Side-channel attacks such as Spectre that utilize speculative execution to steal application secrets pose a significant threat to modern computing systems. While program transformations can mitigate some Spectre attacks, more advanced attacks can divert control flow speculatively to bypass these protective instructions, rendering existing defenses useless. In this paper, we present Venkman: a system that employs program transformation to completely thwart Spectre attacks that poison entries in the Branch Target Buffer (BTB) and the Return Stack Buffer (RSB). Venkman transforms code so that all valid targets of a control-flow transfer have an identical alignment in the virtual address space; it further transforms all branches to ensure that all entries added to the BTB and RSB are properly aligned. By transforming all code this way, Venkman ensures that, in any program wanting Spectre defenses, all control-flow transfers, including speculative ones, do not skip over protective instructions Venkman adds to the code segment to mitigate Spectre attacks. Unlike existing defenses, Venkman does not reduce sharing of the BTB and RSB and does not flush these structures, allowing safe sharing and reuse among programs while maintaining strong protection against Spectre attacks. We built a prototype of Venkman on an IBM POWER8 machine. Our evaluation on the SPEC benchmarks and selected applications shows that Venkman increases execution time to 3.47$ imes$ on average and increases code size to 1.94$ imes$ on average when it is used to ensure that fences are executed to mitigate Spectre attacks. Our evaluation also shows that Spectre-resistant Software Fault Isolation (SFI) built using Venkman incurs a geometric mean of 2.42$ imes$ space overhead and 1.68$ imes$ performance overhead.

研究の動機と目的

• フェンスやSFIのようなソフトウェア緩和策を回避するBTBおよびRSBの汚染を利用したSpectre Variant-2攻撃に対処すること。
• ハードウェアマイクロコードの更新を必要とせず、BTBおよびRSBの汚染を完全に緩和するソフトウェアオンリーの防御を設計すること。
• すべての制御転送先をバンドル単位で揃えることで、スペキュラティブ実行が保護命令をスキップできないようにすること。
• BTBおよびRSBの共有を安全に保ちつつ、強力なセキュリティ保証を維持すること。
• 実世界のワークロードにおける防御のパフォーマンスおよびコードサイズのオーバーヘッドを評価すること。

提案手法

• システム上のすべてのコードを変換し、すべての制御転送先が固定サイズのバンドルの開始位置に揃うようにすること。すべてのバンドルは共通の2の累乗境界に揃える。
• 分岐命令を変更し、分岐先のアドレスを直近のバンドル境界に揃えることで、BTBおよびRSBエントリがすべてバンドルの開始位置を指すようにすること。
• フェンス命令やSFIチェックなどの保護命令を、保護する命令と同じバンドルに挿入することで、スペキュラティブバイパスを防ぐこと。
• 呼び出しおよびリターン命令がバンドルの最後に配置されることを強制することで、リターンアドレスもバンドル境界に揃うようにすること。
• すべてのバイナリが一貫して変換されるように、システムワイドなコンパイルパイプラインと統合することにより、信頼できないコードによるBTBまたはRSBの汚染を防ぐこと。
• IBM POWER8上でプロトタイプを構築し、SPECベンチマークおよび特定のアプリケーションにおけるパフォーマンスおよびコードサイズのオーバーヘッドを評価すること。

実験結果

リサーチクエスチョン

• RQ1 ハードウェアマイクロコードの更新に依存せず、BTBおよびRSBの汚染を利用したSpectre攻撃をソフトウェアオンリーの防御で防げるか？
• RQ2 コード変換により、フェンスやSFIチェックのようなセキュリティクリティカル命令をスペキュラティブ実行がバイパスできないようにできるか？
• RQ3 BTBおよびRSBエントリをプログラム間で安全に共有しながら、スペキュラティブ制御フローハイジャックを防げるか？
• RQ4 バンドル単位の揃えと保護命令の配置によるパフォーマンスおよびコードサイズのオーバーヘッドはどの程度か？
• RQ5 SFIやフェンスのような既存の防御策を、戦略的なコード配置によってBTB/RSBの汚染に対して耐性を持たせられるか？

主な発見

• Venkmanを用いてSpectre Variant-1の緩和にフェンスを挿入した場合、SPECベンチマークで平均実行時間が3.47倍に増加した。
• バンドル揃えおよび保護命令の挿入により、平均コードサイズが1.94倍に増加した。
• Venkmanで構築されたSpectre耐性のあるソフトウェアフォールト隔離（SFI）は、空間的オーバーヘッドが幾何平均2.42倍、パフォーマンスオーバーヘッドが1.68倍であった。
• Venkmanは、すべてのスペキュラティブ制御転送がバンドル境界に揃ったターゲットに制限されることを保証し、保護命令のバイパスを防いだ。
• この防御は、BTBおよびRSBエントリをプログラム間で安全に共有でき、フラッシュや特権レベルの隔離を必要としない。
• VenkmanのアプローチはIBM POWER8で有効であり、x86およびARMにも拡張可能であるが、移植は今後の作業に任せた。