论文阅读—InvisiSpec

InvisiSpec: Making Speculative Execution Invisible in the Cache Hierarchy

论文链接: InvisiSpec

背景

针对推测攻击的主流防御措施面临安全性不完备和高性能开销的问题。

概述

文章重点在解决两个问题：

1. 延缓不安全的数据写入Cache
2. 保证多处理器下的内存一致性
   
   分别针对Spectre和Futuristic提供不同解决方案（futuristic安全要求更为严格）

方法

大致思路： 在L1 DCache层级设计一个类似的结构SB，SB对其他线程不可见。USL先将数据存储在这里，当USL被认为安全（位于ROB头部或其ROB位置之前的指令都已安全）时可以提交时，SB中存储的数据重新加载一遍（时间开销的主要来源）。

文章定义的一些概念：
SB： Speculative Buffer
USL： Unsafe Speculative Loads

细节

1. 内存一致性：在SB中数据reload或者说在USL变的可见前，需要进行曝光或者验证。

   • 曝光（exposure）：直接重新加载数据
   • 验证（validation）：如果SB中的数据和内存当前最新的数据不一样，那么USL及其后续指令都需要刷新
     

2. 高性能：

   • 尽可能多使用曝光。如果ROB中当前USL前的所有load指令都已经获取了请求的数据，则可将验证转为曝光
   • 尽可能早的刷新指令。Core在收到cache line的无效信号后，直接刷新SB中对应请求该数据的USL
   • 尽可能多让曝光和验证重叠执行。
     • 重叠执行看做原子事务
     • 必须严格按照程序中指令顺序曝光或验证
     • Futuristic中，任何重叠的事务都不能更改cache状态
   • 尽可能多复用数据。在LLC中设置LLC-SB，暂存验证或曝光中使用到的数据。当USL指令validation or exposure时，USL从LLC-SB中获取数据；当这中间其他核改了内存中的对应数据，LLC-SB中的数据将会被置为无效，保证内存一致性

实验结果

实验配置了五种处理器：

在SPEC 2006上采集的数据：

实验实现上作者做了很多优化细节加速，时间开销上效果不错