security - 为什么 CPU 推测执行不会导致 OOB 程序崩溃？

Question

问题源于阅读 Spectre attack paper .如果我理解正确的话，攻击源于 CPU 启发式推测执行(错误的)代码分支的可能性。考虑示例(在 C 中):

int arr[42];
if (i < 42) {
    int j = arr[i];
}

如果我对论文的理解正确，即使在 i >= 42 时，也可以(在某些情况下)推测执行 int j = arr[i]。我的问题是——当我在其边界之外访问数组时，我的程序经常会崩溃(Linux 上的段错误，Windows 上的“程序执行了非法操作”错误)。

为什么在数组越界访问时推测执行不会导致程序崩溃？

Answer 1

关键在于，在现代 CPU 中，动词 executing 并不代表您认为的意思。

执行指令是计算其输出和副作用(如果有)的行为。
但是，这不会改变程序状态。
乍一看这似乎很难理解，但实际上并没有什么奇怪的。

CPU 有一个相当大的内部存储器，由它的所有寄存器组成，大部分存储器对程序员不可见，它所在的部分被称为架构状态.
架构状态 (AS) 是 CPU 手册中记录的内容，也是由一系列指令(例如程序)更改的内容。

由于更改 AS 只能通过 ISA(手册)中给出的语义发生，并且 ISA 指定了串行语义(指令按程序顺序一个接一个地完成)，因此不允许并行。
然而，现代 CPU 有很多资源(称为执行单元)可以独立完成它们的工作。

为了利用所有这些资源，CPU 的前端(负责从内存层次结构中读取指令并将其提供给执行单元的部分)能够在每个周期内访问、解码和输出多条指令.
前端和后端(执行单元所在的位置)之间的边界不再真正处理指令(而是使用 uops)，但这是 x86 CISC 的麻烦。

所以现在 CPU 一次有 4/6 微指令“执行”，但如果 ISA 是串行的，除了排队这些微指令之外它还能做什么？
好吧，前端的设计使得这些 uops 不在 AS 上运行，而是在 shadow state(SS，我的术语在这里)，它们的操作数被重命名，由 big 的一部分组成CPU 的无形内存。
并行或乱序更改都可以，因为它不是 AS。
这就是执行:改变 SS。

真的值得吗？毕竟重要的是 AS。
好吧，与执行相比，将 SS 转移到 AS 确实很快，所以值得。
这是一个“重命名”(反转之前的重命名)的问题，它被称为 retiring 指令。

其实，退休不止于此。
由于执行不会影响 AS，因此副作用也应该不会影响它。
这些副作用包括异常，但推测性地处理异常过于繁琐(需要协调大量资源)，因此异常处理延迟直到退休。
这也具有在处理异常时拥有正确 AS 的优势，以及仅在实际必须出现时才引发异常的优势。

推测执行的要点是打赌，CPU 打赌指令序列不会产生任何异常(包括缺页错误)，因此在大多数检查关闭的情况下执行它(我不能排除，在我的脑海中，无论如何都没有进行一些检查)从而获得了很多优势。
当需要取消这些指令时，将检查投注，如果有任何失败，SS 将被丢弃。

这就是推测性执行不会使您的程序崩溃的原因。

Spectre 所依赖的事实是，推测性执行确实在某种意义上改变了 AS:缓存没有失效(再次出于性能原因，当下注关闭时，SS 不会简单地复制到 AS 中)和时间攻击是可能的。
这可以通过多种方式纠正，包括在从 TLB 读取时执行基本权限检查(毕竟只使用权限 0 和 3，因此逻辑很简单)或向缓存行添加一位以将其标记为推测性(被非推测代码视为无效)。