标签: cpu-mds

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

我正在尝试获取这些漏洞背后的微架构细节。我已经开始使用 MSBDS，也称为 Fallout (cfr Meltdown)，它允许攻击者泄漏存储缓冲区的内容。

出于某种原因，讨论微架构细节的网络安全论文通常不准确。
幸运的是，MSBDS 论文引用了专利 US 2008/0082765 A1（图片来自该专利）。

对于我收集到的信息，似乎在 MSBDS 的情况下，漏洞存在于内存消歧算法如何处理具有无效物理地址的负载。

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

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

[0026]段补充说：

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

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

这确实是研究人员如何展示他们的攻击：

char * victim_page = mmap (... , PAGE_SIZE …

我正在阅读 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 缓存，则将请求放入行填充缓冲区
6. Line Fill Buffer 将无效读取请求转发到 L2
7. 某些缓存接收无效读取并发送其缓存行
8. 存储缓冲区将其值应用于传入的缓存行
9. 嗯？行填充缓冲区将条目标记为无效

问题

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