问题标签 [spectre]

因此，我最近在 The Register 上阅读了一篇文章，内容是关于 Spectre/Meltdown 缓解的微码更新对纯计算事物的影响。

链接的文件指定这是针对未优化的代码，这似乎意味着可以进行一些优化，专门用于处理缓解补丁。Register 文章和研究论文都没有详细说明这些优化可能是什么。但是，这只是暗示。搜索“Spectre/Meltdown optimization”当然只会返回有关这些漏洞如何攻击处理器分支预测优化的结果。

所以我的问题是，作为一名程序员，我可以做些什么来优化补丁系统上的代码？

我想看看幽灵缓解标志如何解决一个问题，以说服我的团队我们需要将此标志添加到我们即将进行的项目的大型代码库中。

我正在搜索具有幽灵漏洞的示例项目，并通过添加上周在 Visual Studio 2017 中引入的幽灵缓解标志来解决。

有人可以帮助我通过 POC 向我的更大团队演示，了解 Microsoft 最近在 Visual Studio 中添加的支持如何克服这个问题吗？

这是 Microsoft 为 VS 2017 提供的最新版本说明。

编辑问题：2018 年 8 月 23 日

在寻求答案的过程中，我尝试了以下代码形式的 microsoft Spectre Mitigation 页面：

当我在启用幽灵缓解标志的情况下编译代码时：

项目属性 > 配置属性 > C/C++ > Spectre 缓解 > 已启用

还需要进行三项额外的更改来合并此更改：

1. 在优化中从 /Od 更改为 /O2

项目属性 > 配置属性 > C/C++ > 优化 > /O2

2. 基本运行时检查为默认值

项目属性 > 配置属性 > C/C++ > 代码生成 > 基本运行时检查 > 默认

3. 将 VC 库目录添加到链接器路径

项目属性 > 配置属性 > 链接器 > 常规 > 附加库目录 > C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86

注意：而不是像这样硬编码路径

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86

，您可以像这样使用 Visual Studio 变量：

$(VCToolsInstallDir)\lib\x86\

我得到以下输出：

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(402,5): 警告 MSB8038: Spectre 缓解已启用但 Spectre 缓解库未找到. 验证 Visual Studio 工作负载是否包含 Spectre 缓解库。有关详细信息，请参阅https://aka.ms/Ofhn4c 。

我现在不知道该怎么办。我得到了一个输出可执行文件，但我希望 Spectre 缓解功能是可测试的。请帮我。

有谁知道是否有一个地方可以让我了解有关 Spectre V4（推测存储绕过）漏洞的更多信息？我已经知道 V1-V3 和 Foreshadow。我发现 英特尔的描述有点混乱，尤其是他们的示例代码（我在这里复制了它）

由于最后两条指令之间存在真正的依赖关系，处理器如何推测性地执行最后一次加载。（我认为乱序执行仍然应该尊重真正的依赖，对吧？）

在 Spectre 变体 2 中，分支目标缓冲区 (BTB) 可能在另一个进程中中毒。如果分支预测器也使用虚拟地址来索引分支，为什么我们不能像在 Spectre v1 攻击中训练 BTB 那样训练分支预测器？

在 Spectre论文中，PoC 将 Victim 和 Attacker 代码放在同一进程中。

代码是这样的：

所以攻击者和受害者可以使用相同的array2（因为它们在相同的代码、进程中）。

但在现实世界中，攻击者和受害者是分开的（它们是不同的进程），所以他们不能共享array2。

所以这是我的问题，在这种情况下，攻击者如何测量访问时间array2？
攻击者如何知道array2的地址？

我不知道如何攻击者访问array2. 这里有什么误解？

我对来自 Windows 的 Spectre/meltdown 补丁有疑问（它是在去年第一季度左右发布的）。激活后，我的 delphi REST 服务会减慢大约 15 倍（因此，如果请求需要 1 秒，则激活的补丁大约需要 15 秒）。我已经追踪到数据库连接的减速。不知何故，从参数全部设置后，到 sql 文本的转换需要很长时间，然后数据库本身的执行时间比平时要长得多。首先，我通过将 sql 语句减少到几行来帮助自己，它变得更快（所以更多的行意味着更多的时间。大约就像，如果你在更新/插入语句中再添加一行，它需要 0.2-0.3处理事务需要几秒钟。据我所知，选择语句工作正常）。在我在其他请求上遇到同样的问题之后，应用程序仍在开发中，我关闭了补丁，一切都变得更快了。现在管理员坚持打补丁，问题又来了。

有没有人遇到过这样的事情，或者是否有可能将应用程序排除在补丁的目标之外？奇怪的是，我还有一个使用相同业务逻辑的客户端/服务器应用程序。客户端/服务器应用程序也在变慢，但大约是 2 倍左右。所以这就是我不太明白的事情。使用相同的功能，从服务内部比从客户端/服务器应用程序花费更长的时间。

是的，我正在使用 devart 进行数据库连接，它是一个 mssql 服务器（2016 年）。该服务和客户端/服务器应用程序是用delphi XE7编写的（现在正在尝试更新do Xe10.2，希望这会有所帮助）

谢谢

我已经阅读了一些关于 Spectre v2 的内容，显然你得到了非技术性的解释。Peter Cordes 有更深入的解释，但并没有完全解决一些细节。注意：我从未执行过 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]（包含秘密数据的特定内存地址（data[1000]），目标是从内存加载到缓存），那么这将被推测性地分配给加载缓冲区。前面的间接分支还在分支执行单元中等待完成。

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

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

从命名和这篇文章我觉得答案是否定的，但我不明白为什么。瓶颈是从内存中获取数据的速度。您是否可以同时获取指令似乎并不重要。不是还要等到数据到来吗？假设获取数据需要 100 个 cpu 周期，执行指令需要 1 个，那么提前完成 1 个周期的能力似乎并没有很大的改进。我在这里想念什么？

背景：我看到这篇文章说 Spectre 错误不会因为投机执行而得到修复。我认为投机执行，例如分支预测，对哈佛架构也有意义。我对吗？我知道投机执行对冯诺依曼架构更有利，但有多少呢？谁能给个粗略的数字？我们可以说幽灵会在多大程度上因为冯诺依曼架构而存在？

我正在尝试从InvisiSpec paper复制数据。InvisiSpec 是一种针对 Spectre 攻击的硬件防御机制。我正在使用论文作者发布的 github代码。

目前我可以在我的系统上成功构建和运行最新版本的 gem5 模拟器。但是，在尝试构建他们的代码时出现以下异常

我不知道这个错误来自哪里。我浏览了很多东西，但没有任何成功。如果有人可以帮助我找到导致异常的原因，我将不胜感激。该问题也发布在相应的github 存储库中。

我正在尝试从InvisiSpec paper复制数据。InvisiSpec 是一种针对 Spectre 攻击的硬件防御机制。我正在使用论文作者发布的 github代码。我之前在 Gem5 上构建 InvisiSpec 时遇到了问题，但现在这个问题已经解决了。

目前，此存储库中的 Gem5 在我的系统上构建时没有错误。并使用以下方案成功完成运行它。

然而SpectreSafeInvisibleSpec，方案因核心转储而中止。显然泄漏的来源来自satisfyRequest缓存中的函数：

我尝试为更少的指令以及不同的缓存配置和不同的 TSO 运行此方案，但没有成功。

这是回溯：

在相应的github存储库中也报告了此问题。