x86 - Spectre (v2) 的内部工作原理

Question

我已经阅读了一些关于 Spectre v2 的书，显然你得到了非技术性的解释。 Peter Cordes 有更深入的explanation但它并没有完全解决一些细节。注意:我从未执行过 Spectre v2 攻击，所以我没有实际经验。我只阅读了有关该理论的内容。

我对 Spectre v2 的理解是你做了一个间接的分支预测错误，例如 if (input < data.size) .如果间接目标阵列(我不太确定它的细节——即为什么它与 BTB 结构分开)——在解码间接分支的 RIP 时重新检查——不包含预测，那么它将插入新的跳转 RIP(分支执行最终会插入分支的目标 RIP)，但目前它不知道跳转的目标 RIP，因此任何形式的静态预测都不起作用。我的理解是它总是会预测新的间接分支不会被采用，当端口 6 最终计算出跳转目标 RIP 和预测时，它将使用 BOB 回滚并使用正确的跳转地址更新 ITA，然后更新本地和全局分支历史寄存器和相应的饱和计数器。

黑客需要训练饱和计数器以始终预测采取的措施，我想，他们通过运行 if(input < data.size) 来做到这一点。循环多次，其中 input设置为确实小于 data.size (相应地捕捉错误)并在循环的最后一次迭代中，使 input超过data.size (例如 1000)；将预测采用间接分支，并将跳转到发生缓存加载的 if 语句的主体。

if 语句包含 secret = data[1000] (包含 secret 数据的特定内存地址 (data[1000]) 的目标是从内存加载到缓存)然后这将被推测性地分配给加载缓冲区。前面的间接分支仍在分支执行单元中等待完成。

我相信前提是在错误预测刷新加载缓冲区之前需要执行加载(分配一个行填充缓冲区)。如果它已经被分配了一个行填充缓冲区，那么什么都不能做。没有取消行填充缓冲区分配的机制是有道理的，因为行填充缓冲区在将其返回到加载缓冲区之后存储到缓存之前必须挂起。这可能会导致行填充缓冲区变得饱和，因为不是在需要时解除分配(将其保留在那里以加快其他加载到同一地址的速度，但在没有其他可用的行缓冲区时解除分配)。在它收到一些不会发生刷新的信号之前，它无法解除分配，这意味着它必须暂停以执行前一个分支，而不是立即使行填充缓冲区可用于其他逻辑内核的存储。这种信号机制可能难以实现，也许他们没有想到(前 Spectre 思维)，而且如果分支执行需要足够的时间来挂起行填充缓冲区导致性能影响，即如果data.size在循环的最后一次迭代之前有意从缓存中刷新 ( CLFLUSH )，这意味着分支执行可能需要多达 100 个周期。

我希望我的想法是正确的，但我不是 100% 确定。如果有人要添加或更正任何内容，请执行。

Answer 1

有时术语“BTB”统称为分支预测单元使用的所有缓冲器。然而，实际上有多个缓冲区，所有缓冲区都在每个循环中用于进行目标和方向预测。具体来说，BTB用于对直接分支进行预测，ITB(间接目标缓冲区)用于对返回以外的间接分支进行预测，RSB用于对返回进行预测。 ITB 也称为 IBTB 或间接目标阵列。所有这些术语都被不同的供应商和研究人员使用。通常，BTB 用于在其他缓冲区未命中时对各种分支指令进行初始预测。但后来预测器了解了更多关于分支的信息，其他缓冲区开始发挥作用。如果同一间接分支的多个动态实例都具有相同的目标，则也可以使用 BTB 代替 ITB。当同一分支具有多个目标并且专门设计用于处理此类分支时，ITB 会更加准确。见:Branch prediction and the performance of interpreters — Don't trust folklore .第一个实现独立 BTB 和 ITB 结构的 Intel 处理器是 Pentium M。后来 Intel Core处理器有专用的 ITB。

Spectre V1 漏洞利用基于使用攻击者程序训练 BTB，以便当受害者执行别名相同 BTB 条目的分支时，处理器被诱骗推测性执行指令(称为小工具)以泄漏信息。 Spectre V2 漏洞利用与此类似，但基于对 ITB 的训练。这里的关键区别在于，在 V1 中，处理器错误地预测了分支的方向，而在 V2 中，处理器错误地预测了分支的目标(并且，在条件间接分支的情况下，方向也是如此，因为我们希望它被带走)。在解释、JIT 编译或使用动态多态的程序中，可以有许多间接分支(除了返回)。一个特定的间接分支可能永远不会去某个位置，但是通过错误训练预测器，它可以跳到我们想要的任何地方。也正是因为这个原因，V2 非常强大；无论小工具在哪里，也不管程序的有意控制流是什么，您都可以选择间接分支之一并使其推测性地跳转到小工具。

请注意，通常静态直接分支的目标的线性地址在程序的整个生命周期中保持不变。只有一种情况可能并非如此:动态代码修改。因此，至少在理论上，可以基于直接分支的目标错误预测来开发 Spectre 漏洞利用。

关于LFB的回收，我真的不明白你在说什么。当错过 L1D 的加载请求将数据接收到 LFB 中时，数据会立即转发到管道的旁路互连。需要有一种方法来确定哪个负载 uop 请求了此数据。返回的数据必须标有负载的 uop ID。 RS 中等待数据的 uop 的来源表示为负载的 uop ID。另外，需要将持有加载 uop 的 ROB 条目标记为已完成，以便可以将其引退，并且在 pre-SnB 中，需要将返回的数据写入 ROB。如果在管道刷新时未取消 LFB 中未完成的加载请求，并且如果加载 uop ID 被重用于其他一些 uop，则当数据到达时，它可能会被错误地转发到当前管道中的任何新 uop，从而破坏微架构状态。因此，需要有一种方法来确保在任何情况下都不会发生这种情况。通过简单地将所有有效的 LFB 条目标记为“已取消”，非常有可能取消管道刷新中未完成的加载请求和推测性 RFO，这样数据就不会返回到管道中。但是，数据可能仍会被提取并填充到一级或多级缓存中。 LFB 中的请求由行对齐的物理地址标识。可以有其他可能的设计。

我决定进行一项实验，以确定在 Haswell 上释放 LFB 的确切时间。下面是它的工作原理:

Outer Loop (10K iterations):

Inner Loop (100 iterations):
10 load instructions to different cache lines most of which miss the L2.
LFENCE.
A sequence of IMULs to delay the resolution of the jump by 18 cycles.
Jump to inner.

3 load instructions to different cache lines.
LFENCE.
Jump to outer.

为此，需要关闭超线程和两个 L1 预取器，以确保我们拥有 L1 的所有 10 个 LFB。
LFENCE指令确保我们在正确预测的路径上执行时不会耗尽 LFB。这里的关键思想是每次外部迭代都会错误预测一次内部跳转，因此可以在 LFB 中分配最多 10 个位于错误预测路径上的内部迭代负载。请注意 LFENCE防止分配来自以后迭代的负载。几个周期后，内部分支将被解析并发生错误预测。管道被清除，前端被重新引导以获取和执行外循环中的加载指令。

有两种可能的结果:

已分配给错误预测路径上的负载的 LFB 作为管道清理操作的一部分立即释放，并可供其他负载使用。在这种情况下，不会因为 LFB 不可用而出现停顿(使用 L1D_PEND_MISS.FB_FULL 计算)。

仅当负载得到服务时才释放 LFB，而不管它们是否处于错误预测的路径上。

内跳后外循环有3个负载时，实测值 L1D_PEND_MISS.FB_FULL大约等于外部迭代的次数。这是每个外循环迭代一个请求。这意味着当正确路径上的三个负载被发送到 L1D 时，来自错误预测路径的负载仍然占用 8 个 LFB 条目，导致第三个负载的 FB 满事件。这表明 LFB 中的加载仅在加载实际完成时才被解除涂层。

如果我在外循环中放入少于两个负载，则基本上不会有 FB full 事件。我注意到一件事:对于超过三个负载的外循环中的每一个额外负载， L1D_PEND_MISS.FB_FULL增加了大约 20K，而不是预期的 10K。我认为正在发生的事情是，当第一次向 L1D 发出加载 uop 的加载请求并且所有 LFB 都在使用时，它会被拒绝。然后当一个 LFB 可用时，加载缓冲区中未决的两个加载被发送到 L1D，一个将被分配在 LFB 中，另一个将被拒绝。因此，每次额外加载我们会得到两个 LFB 完整事件。然而，当外循环中有三个负载时，只有第三个会等待 LFB，所以我们每次外循环迭代都会得到一个事件。本质上，加载缓冲区无法区分是有一个 LFB 可用还是有两个 LFB；它只会知道至少有一个 LFB 是空闲的，因此它会尝试同时发送两个加载请求，因为有两个加载端口。