[论文解读] 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 是一种纯软件防御机制，通过将所有控制流目标对齐到固定大小的代码块（bundle），防止利用分支目标缓冲区（BTB）和返回栈缓冲区（RSB）污染的Spectre攻击。该机制确保推测执行无法跳过如屏障指令或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.

研究动机与目标

• 解决通过污染BTB和RSB来绕过软件防护（如屏障指令和SFI）的Spectre变种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污染具备抗性？

主要发现

• 在SPEC基准测试中，使用Venkman插入屏障指令以防御Spectre变种1时，平均执行时间增加3.47倍。
• 由于代码块对齐和保护性指令插入，平均代码大小增加1.94倍。
• 基于Venkman构建的Spectre抗性软件故障隔离（SFI）机制，其空间开销几何平均为2.42倍，性能开销几何平均为1.68倍。
• Venkman 确保所有推测性控制流转移均被限制在代码块对齐的目标上，防止绕过保护性指令。
• 该防御机制在保持程序间BTB和RSB条目安全共享方面表现良好，优于需要刷新或特权级隔离的方案。
• Venkman 的方法在IBM POWER8上有效，且可扩展至x86和ARM架构，尽管移植工作留待未来研究。