问题标签 [cpu-mds]

CVE-2018-12126 已被分配给 MSBDS（微架构 StoreBuffer 数据采样），这是英特尔处理器的漏洞，属于新创建的MDS（微架构数据采样）类。

我试图了解这些漏洞背后的微架构细节。我从 MSBDS 开始，也称为 Fallout (cfr Meltdown)，它允许攻击者泄露存储缓冲区的内容。

出于某种原因，讨论微架构细节的网络安全论文往往不够精确。
幸运的是，MSBDS 论文引用了专利 US 2008/0082765 A1（从中拍摄图片）。

据我所知，在 MSBDS 的情况下，漏洞似乎在于内存消歧算法如何处理带有无效物理地址的负载。

这是据称用于检查存储缓冲区中的负载是否匹配的算法：

302检查加载所引用的页面的偏移量是否与存储缓冲区中任何先前存储所引用的页面的偏移量相匹配。
如果此检查失败，则负载与任何存储都不匹配，并且可以在304处执行（它已被分派） 。
如果302进行检查，则将加载的虚拟地址的上半部分与存储的虚拟地址进行检查¹。
如果找到匹配，则加载匹配并且在308转发它需要的数据或者如果转发是不可能的（例如，将存储缩小到更广泛的加载），加载本身被阻塞（直到匹配的存储提交）。
笔记相同的虚拟地址可以映射到两个不同的物理地址（在不同的时间但在存储转发窗口内）。不正确的转发不是通过这种算法来防止的，而是通过排空存储缓冲区（例如，使用mov cr3, X正在序列化的 a）²来防止。
如果加载的虚拟地址不匹配存储的任何虚拟地址，则在310检查物理地址。
这是处理不同虚拟地址映射到相同物理地址的情况所必需的。

第[0026]段补充说：

在一个实施例中，如果在操作302存在命中并且加载或存储操作的物理地址无效，则在操作310的物理地址检查可以被认为是命中并且方法300可以在操作308继续。在一种情况下，如果加载指令的物理地址无效，则加载指令可能由于DTLB 118未命中而被阻塞。此外，如果存储操作的物理地址无效，则结果可以基于一个实施例中的finenet命中/未命中结果，或者可以在该存储操作上阻止加载操作直到存储操作的物理地址被解析在一个实施例中。

这意味着如果物理地址不可用，CPU 将只考虑地址的低 (12) 位³。
考虑到 TLB 未命中的情况在下面几行中得到解决，这仅留下访问页面不存在的情况。

这确实是研究人员提出他们的攻击的方式：

我不确定还有什么会导致无效的物理地址（对特权页面的访问返回正确的物理地址）。

真的是对无效物理地址的处理触发了MSBDS漏洞吗？

¹ SBA（存储缓冲区地址）组件包含存储的虚拟地址和物理地址，可能只是物理地址的一部分（其余部分位于专用数组中，可能命名为物理地址缓冲区）。
²我不清楚是否真的有可能通过将页表条目更改为指向其他地方然后发出invlpg.
³我对此的理由是，由于我们不处于可恢复的情况下，负载出现故障，跳过另一个检查以冒不正确转发的风险在性能方面是值得的，因为它会使负载提前退出（和故障）。

我正在尝试了解RIDL类漏洞。

这是一类能够从各种微架构缓冲区读取陈旧数据的漏洞。
今天已知的漏洞利用：LFB、加载端口、eMC 和存储缓冲区。

链接的论文主要集中在 LFB。

我不明白为什么 CPU 会用 LFB 中的陈旧数据来满足负载。
我可以想象，如果负载在 L1d 中命中，它会在内部“重放”，直到 L1d 将数据带入 LFB 信号通知 OoO 核心停止“重放”它（因为读取的数据现在有效）。

但是我不确定“重播”实际上是什么意思。
我认为负载被分派到具有负载能力的端口，然后记录在负载缓冲区（在 MOB 中），并最终根据需要保持，直到它们的数据可用（由 L1 发出信号）。
所以我不确定“重播”是如何发挥作用的，此外，为了让 RIDL 工作，每次“播放”负载的尝试也应该解除阻塞相关指令。
这对我来说似乎很奇怪，因为 CPU 需要跟踪加载正确完成后要重播的指令。

关于 RIDL 的论文使用此代码作为示例（不幸的是，我不得不将其粘贴为图像，因为 PDF 布局不允许我复制它）：

它可以工作的唯一原因是，如果 CPU 将首先用过时的数据满足第 6 行的负载，然后重放它。
这似乎证实了以下几行：

具体来说，我们可能期望两个访问速度很快，而不仅仅是与泄露信息对应的一个。毕竟，当处理器发现错误并在第 6 行以正确的值重新启动时，程序也会使用该索引访问缓冲区。

但我希望 CPU 在转发 LFB（或任何其他内部缓冲区）中的数据之前检查负载的地址。
除非 CPU 实际重复执行加载，直到它检测到加载的数据现在有效（即重放）。
但是，为什么每次尝试都会解除对相关指令的阻塞？

重放机制究竟是如何工作的（如果它存在的话），以及它如何与 RIDL 漏洞交互？

我的解释是，在 TLB 未命中时，PMH 遍历页表并将填充加载到加载缓冲区中；如果它遇到需要设置的访问位或脏位，它会传达一个异常代码，该代码将标记加载退出（假设它还将加载需要帮助的虚拟地址放置在 MSROM 例程可访问的位置）。

当它退休时触发异常，导致管道被刷新，并且特定的 MSROM 特殊 uop 在分配阶段表现出来，这将重新执行整个步行（不知道为什么 PMH 不能自己执行填充写入，但是这个是关于会发生什么的普遍信念）。这看起来确实很奇怪，因为这意味着必须有一个 uop 指示存储到一个物理地址，如果 PMH 执行填充存储，就不必有这样的 uop。如果遇到无效或受保护的位，特殊的 MSROM uop 问题将不得不跳转到页面错误异常例程。如果不需要设置脏/访问位，则将由 PMH 传达页面错误异常代码。

该论文建议继续加载，L1d 缓存控制器只是返回——而不是一个虚拟值或 0 以及取消加载的异常代码——行填充缓冲区的内容可能仍包含由其他逻辑填充的内容核心（然后可用于暂时修改缓存以进行缓存定时攻击）。

这只是英特尔的一个愚蠢错误吗？前所未有的副作用？

我正在阅读 MDS 攻击论文RIDL: Rogue In-Flight Data Load。他们讨论了 Line Fill Buffer 如何导致数据泄漏。关于RIDL 漏洞和负载的“重放”问题讨论了漏洞利用的微架构细节。

阅读该问题后我不清楚的一件事是，如果我们已经有一个存储缓冲区，为什么我们需要一个行填充缓冲区。

John McCalpin 在 WC-buffer 如何与 LFB 相关中讨论了存储缓冲区和行填充缓冲区是如何连接的？在英特尔论坛上，但这并没有真正让我更清楚。

对于存储到 WB 空间，存储数据保留在存储缓冲区中，直到存储退出之后。一旦退役，数据可以写入 L1 数据缓存（如果该行存在并且具有写入权限），否则为存储未命中分配一个 LFB。LFB 最终会收到缓存行的“当前”副本，以便将其安装在 L1 数据缓存中，并将存储数据写入缓存。合并、缓冲、排序和“捷径”的细节尚不清楚......与上述合理一致的一种解释是，LFB 用作缓存行大小的缓冲区，其中存储数据在发送到之前被合并。 L1 数据缓存。至少我认为这是有道理的，但我可能忘记了一些事情......

我最近才开始阅读乱序执行，所以请原谅我的无知。这是我对存储如何通过存储缓冲区和行填充缓冲区的想法。

1. 在前端安排存储指令。
2. 它在存储单元中执行。
3. 存储请求被放入存储缓冲区（地址和数据）
4. 无效读取请求从存储缓冲区发送到缓存系统
5. 如果它错过了 L1d 缓存，则将请求放入 Line Fill Buffer
6. Line Fill Buffer 将无效读取请求转发到 L2
7. 一些缓存接收到无效读取并发送其缓存行
8. 存储缓冲区将其值应用于传入的缓存行
9. 呃？行填充缓冲区将条目标记为无效

问题

1. 如果存储缓冲区已经存在来跟踪超出的存储请求，为什么我们需要行填充缓冲区？
2. 我的描述中的事件顺序是否正确？

RIDL 漏洞利用需要攻击者触发页面错误才能从行填充缓冲区读取陈旧数据。但是根据关于 RIDL 漏洞和负载的“重放”，也可以使用辅助负载。

该问题九次提到辅助/辅助负载，但我仍然无法理解这种负载的作用或触发方式。这与 TLB 相关，并且“导致需要微码辅助的页面浏览”。

有人可以解释一下辅助/辅助负载是什么，最好用一个已解决的例子吗？