security - 如何使用 GCC 和 Clang(或一般的 LLVM)减轻 Spectre

Question

微软添加了一个方便的/Qspectre到他们的 MSVC 编译器(尽管目前似乎只是(试图)减轻 Spectre v1)他们将随着时间的推移进行更新。从用户的角度来看，这非常好，只需启用该标志，您就可以获得他们存储的最新和最大的缓解措施。

使用 LLVM 和 GCC，它看起来有点不同。我认为他们的缓解措施尚未正式发布。

LLVM 应该得到一个 -mretpoline编译器标志，通过间接调用的返回蹦床来缓解 Spectre v2。

另一方面，GCC 有补丁添加了三个编译器选项来缓解 Spectre v2:

-mindirect-branch可以设置为 thunk .按照我的理解，这会为每个间接调用创建 retpolines。

-mfunction-return可以设置为 thunk .我想这对每个函数返回都使用这些 retpolines，这对 Skylake 来说可能是必要的，因为这些处理器还可以预测返回？

-mindirect-branch-register这使用寄存器而不是堆栈来存储间接调用的地址？

所以我很困惑。什么编译器选项可以减轻用户空间应用程序所需的内容和情况？

通常打开它们是个好主意吗？如果针对甚至没有任何推测执行的处理器架构(如微处理器)进行编译，它们是否也会生成这些 retpolines？

Spectre v1 怎么样？

更新:

让我问更准确的问题:

我对编译器选项的理解是否正确？

GCC 选项是在任何地方应用还是仅在具有推测执行功能的处理器上应用？

LLVM 选项是在任何地方应用还是仅在具有推测执行功能的处理器上应用？

这些选项究竟减轻了什么(它们是否完全减轻了幽灵 v2)？

让我们考虑一下我要求的所有其他“奖励”问题，这些问题很高兴知道但对我的问题并不重要。

Answer 1

我对编译器选项的理解是否正确？

我想是这样。

GCC 选项是在任何地方应用还是仅在具有推测执行功能的处理器上应用？

到目前为止，这些选项是特定于 x86 的。我没有检查是否有等效的 ARM 补丁，但无论如何，这些选项将至少部分取决于处理器架构。

我只看了一些 patches ，但看起来并没有强加额外的运行时检查。相反，如果设置了选项，则更改指令选择以防止后端发出不需要的间接跳转。

因此，该选项不适用于完全不相关的架构，但不会尝试发现特定 CPU 在运行时是否易受攻击。
请注意，最知名的 x86 处理器自大约以来已售出。 Pentium Pro 确实使用推测执行。

这些选项究竟减轻了什么(它们是否完全减轻了幽灵 v2)？

大多数情况下，它们通过确保在相应的间接调用中不会发生攻击者控制的推测，从而减轻分支目标注入(inject) (Spectre v2)。

Retpolines 通过使用 return 指令跳转到目标地址来实现这一点，它使用不同的分支预测器，基本上记住最新调用来自哪里。这由在返回指令之前执行调用指令的生成代码进行操作，通过在调用之后放置 mfence 指令来确保推测的执行将陷入死胡同。见 this answer更多细节。

分支目标注入(inject)是一个问题，因为正如 Spectre Paper 中所述在“5.1 讨论”下，可能有很多代码映射给攻击者利用。讨论讨论的是 Windows，但我可以想象，在 Linux 中也必须有一些来自共享库的代码。如果该代码的地址更随机，则利用可能会更难，但如果不检查，我不会指望这一点。特别是 Linux 内核包含大量代码，攻击者可以利用这些代码注入(inject)任意分支目标。

-mfunction-return

乍一看，用更复杂的返回来保护返回似乎很愚蠢，但根据 this message David Woodhouse 提出该选项是 Linux 内核开发人员要求的，因为在记住的返回地址(基本上是调用堆栈之后的隐藏堆栈)下溢时，一些 CPU 再次拉入全局分支预测器，这可能会被攻击者操纵。所以你的解释是正确的。根据同一消息，Linux 内核并未立即使用此标志。我认为性能影响会很大，因为返回比其他间接分支更常见，而且专门的返回预测将在实践中实现出色的命中率。

-mindirect-branch-register

我不太确定，什么-mindirect-branch-register减轻。显然测试套件中需要它和其他选项，但我还找不到解释。还有 Xen uses此选项与 -mindirect-branch=thunk-extern 一起使用，这意味着他们自己编写 thunk 代码并且不让编译器生成它。
与我最初的猜测相反，这与加载地址时的潜在猜测无关，因为这旨在与防止这种猜测的 retpolines 一起使用。在一些讨论中提到，在堆栈上而不是在寄存器中获取目标地址的 thunk 版本最初与 Intel Control-flow Enforcement Technology 发生冲突。 (欧洲中部时间)。我假设由于 retpolines 以一种不寻常的方式使用返回，CET 阻止了跳跃。然而，根据this discussion ，这些问题似乎已经解决了，并且在支持 CET 的机器上，可以使用其他缓解措施(IBRS_ALL)，这允许 retpoline thunk 再次被间接跳转取代。我认为这个选项本身不会有太大帮助。

更新:幽灵变体 1

最近钱德勒·卡鲁斯 proposed如何缓解 LLVM 中的 Spectre V1。这仍在进行中，尚未发布(截至 2018 年 3 月)。基本思想是在错误推测的路径上屏蔽易受攻击的地址或加载的值，然后才能将其用于副作用。