问题标签 [spectre]

当 Microsoft 开始更新 Visual Studio（15.5 和 15.6 Prev3 和 4）的编译器时，我想知道是否有可能检查是否使用 /qspectre 或等于 /d2guardspecload 开关编译了可执行文件，因为可以使用ASLR 和 DEP？

此致

为什么 Meltdown 和 Spectre 漏洞这么长时间没有被发现？

近 20 年来，这些错误一直存在于 CPU 中，考虑到对所有使用这些处理器的计算机的严重影响，为什么不早点发现呢？

在幽灵漏洞描述文件中，我们可以看到它谈到了这个特定的漏洞。

根据论文，在幽灵漏洞中，他们首先为 x 传递许多合法值，以便分支预测器得到训练并开始推测下一条语句，即开始执行y = array2[array1[x] * 256];。并且经过足够长的迭代，当分支预测器被训练时，x 的恶意值被传递，在这种情况下，处理器开始推测执行y = array2[array1[x] * 256];，这一次它加载array1[x]到缓存中，目前无法恢复，可以被攻击者使用。通道攻击。

所以我的问题是为什么我们也需要有这个if声明。如果只有这句话

上面的这个语句（没有if）是否应该足以将其加载array1[x]到缓存中。为什么我们甚至需要这个if声明？

Digital Ocean 3 天前重新启动了所有 droplets，但当它们回来时，我的网站已关闭。问题似乎出现了，因为所有相关服务（httpd、mysqld、iptables 等）都处于非活动状态，必须再次激活它们。
首先有没有其他人有同样的问题，
其次我怎么systemctl start/stop/restart <service>能通过droplet的控制台运行（sshd没有运行所以droplet的控制台是进入我系统的唯一方法）？
似乎每当我执行此操作时，控制台都会将我踢开，因为它处于紧急模式。
我不知道它是否有用，但系统是 Fedora 21。

作为学习项目的一部分，我在 Spectre 和 Meltdown PoC 上做了一些工作，以使自己对这个概念更加熟悉。我已经设法使用时钟计时器恢复以前访问的数据，但现在我想知道他们是如何从那时起实际读取物理内存的。

这引出了我的问题：在很多 Spectre v1\v2 示例中，您可以阅读这段玩具代码示例：

x应该等于：attacked_adress - adress_of_array，这将有效地导致z在attacked_adress处获得值。

在这个例子中很容易理解，但实际上他们怎么知道被攻击的地址是什么样的？它是带有偏移量的虚拟地址，还是物理地址，它们如何设法找到“重要内存”首先位于哪里？

几个月来，我们一直在跟踪 Windows 上的 Meltdown 和 Spectre 缓解措施的性能问题。几天前，我们发现了一些奇怪的结果。在我们的 Windows 10 FCU 机器上应用 2018 年 4 月累积更新 (KB4093112) 后，突然间，我们迄今为止观察到的性能影响消失了，并且在未应用缓解措施时，我们运行的所有基准测试都恢复到相同水平。

例如，下面是 CrystalMark 2004R3 报告的 GDI 性能数据（我们运行了多个基准测试以及我们自己的应用程序基准测试，所有这些都导致性能数据回到了 Meltdown/Spectre 之前的水平）

机器是带有 Xeon E52690 v4 x 2（共 28 个内核）的 HP Z840。BIOS 使用来自https://support.hp.com/us-en/document/c05869091的 SP85295 更新的 v2.41 进行更新。

使用https://www.grc.com/inspectre.htm，我检查了启用 Meltdown/Spectre 的标志是否到位。

有谁知道这种行为的原因？我怀疑缓解措施是否会突然恢复到未应用缓解措施时的水平。微软是否有可能意外禁用 2018 年 4 月累积更新的缓解措施？

MSVC 刚刚发布了一个更新，其中添加了一个关于编译器将注入的一些代码的新警告，以减轻（显然是一些小部分）Spectre：

https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-msvc/

这是从他们的“有问题的”代码示例中得出的一个小 MCVE：

“在上面的示例中，代码执行数组边界检查以确保 untrusted_index 小于 array1 的长度。这是确保程序不会读取超出数组边界所必需的。虽然这似乎是合理的正如所写的那样，它没有考虑 CPU 涉及推测执行的微架构行为。”

所以你现在得到一个警告：

警告 C5045：如果指定 /Qspectre 开关，编译器将插入 Spectre 缓解内存负载

这是它告诉您此代码最终可能比您希望的要慢（如果编译/Qspectre）的方式，因为它将提供一些额外的保护。

由于您似乎无法将任何事情视为理所当然，因此我怀疑做出“只是让警告消失”的更改。例如，对于我在此处给出的 MCVE 代码的特定实例，更改untrusted_index < array1_length为untrusted_index != array1_length似乎可以做到这一点。但这是一个可行的补丁，还是他们的警告只是不完整的——在下一次更新中，它也会抱怨这个？

我知道我可以使用 /wd5040 或其他方式禁用警告。但我有兴趣确保如果代码是使用 /Qspectre 编译的，则不会出现减速，并且如果代码不是使用 /Qspectre 编译的，则不会出现警告。我不想到处触摸文件更改<为!=循环条件 - 或其他 - 如果这只是流失。

所以一个更大的问题是，如果有这种基本的合法解决方法模式，为什么没有提到它们？例如，我描述的情况是我控制索引的迭代，不必担心它来自“不受信任的来源”。然而我得到了一个警告，从 切换<到!=让它消失了。为什么？应该有吗？

我正在开发（NASM + GCC 针对 ELF64）一个PoC，它使用一个幽灵小工具来测量访问一组缓存行（FLUSH+RELOAD）的时间。

如何制作可靠的幽灵小工具？

我相信我理解 FLUSH+RELOAD 技术背后的理论，但是在实践中，尽管有一些噪音，我无法产生一个有效的 PoC。

由于我使用的是时间戳计数器并且负载非常规律，因此我使用此脚本来禁用预取器、涡轮增压器并修复/稳定 CPU 频率：

我有一个连续的缓冲区，在 4KiB 上对齐，大到足以跨越 256 个缓存行，由整数GAP行分隔。

我使用这个函数来刷新 256 行。

该函数循环遍历所有行，触摸中间的每一页（每页不止一次）并刷新每一行。

然后我使用这个函数来分析访问。

附录中提供了 MCVE，并且可以克隆存储库。

当汇编GAP设置为 0 时，链接并执行taskset -c 0获取每一行所需的周期如下所示。

从内存中只加载了 64 行。

在不同的运行中输出是稳定的。如果我设置GAP为 1 只从内存中取出 32 行，当然是 64 * (1+0) * 64 = 32 * (1+1) * 64 = 4096，所以这可能与分页有关？

如果在分析之前（但在刷新之后）执行存储到前 64 行之一，则输出将更改为

其他行的任何存储都给出了第一种类型的输出。

我怀疑里面的数学是坏的，但我需要另一双眼睛找出哪里。

编辑

Hadi Brais在修复了输出现在不一致的问题后指出了对易失性寄存器的滥用。
我看到通常在时间较低（~50 个周期）的地方运行，有时在时间较高的地方（~130 个周期）运行。
我不知道 130 个周期的数字来自哪里（内存太低，缓存太高？）。

代码在 MCVE（和存储库）中是固定的。

如果在分析之前执行任何第一行的存储，则输出中不会反映任何更改。

附录 - MCVE

我试图理解 Erik August ( https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 ) 的 Spectre PoC。在第 76 行它说

所以我知道&是按位与并~返回按位补码。如果j%6是0我明白为什么x=FFF.FF0000。但我想知道为什么x=0在其他情况下。为什么不是例如0xFFFF0001？

谢谢你的帮助！

关于spectre安全问题和侧信道攻击。

在x86和ARM中都存在一种方法来禁用特定内存页面上的缓存/推测访问。因此，对这些内存区域的任何侧信道攻击 ( spectre, meltdown) 应该是不可能的。那么，为什么我们不使用它来通过将所有安全信息（密码、密钥等）存储到缓慢但安全的（？）内存区域，同时将不安全的数据放入快速但不安全的普通内存中来防止侧信道攻击呢？这些页面上的访问时间将大大减少（~100），但内核修复也不便宜。所以也许只减少几个内存页面的性能比稍微整体下降要快吗？

它将解决问题的责任从操作系统转移到应用程序开发人员身上，这将是一个巨大的变化。但是希望内核能够以某种方式修复所有错误似乎也不是一个好方法。

所以我的问题是

1. 使用“设备”内存页面真的可以防止此类攻击吗？
2. 它有什么缺点？（除了明显的性能问题）
3. 使用起来有多实用？