我目前的理解是微码更新改变了过时的 VERW 指令的行为，从而导致各种内部处理器缓冲区的刷新
本文VERW描述了指令的新行为。特别是：
- 该
VERW指令保留了相同的现有功能，即它检查指定段是否可从当前特权级别写入。
- 只有指令的内存操作数变体才能保证覆盖 MDS 所利用的缓冲区。寄存器操作数变体可能会或可能不会执行缓冲区覆盖功能。
- 无论段写入权限检查的结果如何（包括异常），都会发生缓冲区覆盖功能。
在VERW本身指令的执行不会阻止所有的MDS-影响缓冲器的前执行后的指令将被覆盖。因此，有必要在VERW. 考虑同一篇文章中的示例：
Code region A (victim accessing secret data)
VERW m16
Code region B (victim accessing data that is not secret)
Speculation barrier (for example, LFENCE)
Code region C (the attacker can only see the data accessed in B)
假设这些指令在带有MD_CLEAR微码更新的处理器上执行（下面讨论）。A 的执行可能会在同一个物理内核上留下一些秘密的动态数据。当VERW开始执行时，B 可能会在所有泄漏缓冲区被覆盖之前执行。需要在 B 之后放置一个屏障，例如LFENCE，以确保 C 无法访问秘密数据。
该VERW指令在实模式和虚拟 8086 模式下不受支持，因为在这些模式下段访问权限不可用。因此，在这些模式下，需要使用依赖于微架构的指令序列。
以下特征VERW解释了为什么英特尔选择使用缓冲区覆盖功能重载该指令（而不是任何其他指令或引入新的 MSR）：
VERW 是微码的，这可能是微码更新工作所必需的。VERW 很少使用，因此由此产生的性能开销在现有软件上实际上是微不足道的。VERW可以在任何特权级别执行。特别是，它可以用于安全边界处于用户模式（例如，SGX 和沙箱）的情况。
VERW虽然并不完美。如上所述，它不适用于实模式和虚拟 8086 模式。它还修改了ZF标志。
根据一篇深入的博客文章，CVE-2018-12130 (MFBDS) 只能通过禁用 SMT 来部分缓解。在系统调用期间，某些信息仍然可以通过上下文切换泄漏。
有两种情况需要分开考虑：
- 攻击者和受害者永远不会同时在同一物理内核的两个线程上运行。当 HT 被禁用或 OS 调度程序决定同时在不同的物理内核上运行线程时（例如，因为线程具有不同的物理内核关联性），可能会发生这种情况。无论哪种方式，线程仍可能在不同时间点在同一逻辑核心上运行。MDS 漏洞利用仍然可以成功。攻击者与受害者运行在同一逻辑内核上的唯一方法是当受害者切换到内核模式（例如，系统调用或硬件中断）时，攻击者被安排在下一个逻辑内核上运行核。因此，内核可以通过执行
VERW返回用户模式之前的指令（在该逻辑核心上调度的任何线程下一个运行）。这也确保缓冲区在返回用户模式时不包含来自内核的内存请求。同样，VERW在同一逻辑核心上的两个虚拟机之间切换时需要执行。
- 攻击者和受害者可能在同一个物理内核上同时运行。MDS 上的 Linux 内核文档提到需要禁用 HT 以进行全面保护，以防止这种特殊情况首先发生。然而，英特尔关于 MDS 的文章提出了一种替代缓解措施，称为组调度。这里的想法是确保两个线程仅在相互信任的情况下才被安排在两个同级逻辑核心上运行。Hyper-V 虚拟机监控程序已经采用了组调度（并且它最近已更新
VERW为在属于不同 VM 的虚拟处理器之间切换时使用）。在执行期间VERW（或替代的软件序列），同级逻辑核心必须被停顿（例如，执行HLT或PAUSE）以确保所有缓冲区都被覆盖。
上述缓解措施（在从内核返回或在 VM 之间切换、禁用 HT 和组调度时覆盖受 MDS 影响的缓冲区）无法保护沙盒应用程序（在 Web 浏览器中）和 SGX 飞地，其中没有特权级别之间的切换. 沙盒应用程序的一种可能缓解措施是改用进程。SGX 飞地受微码更新本身的保护。
该MD_CLEAR微代码更新似乎包括了以下变化：
VERW如上所述的指令的新功能。只有每个特定处理器上易受攻击的缓冲区才会被覆盖，因此VERW对性能的影响取决于处理器。- 当进入或退出 SGX 飞地时，受 MDS 影响的缓冲区将被覆盖。但是，在 enclave 的入口处，必须确保没有不受信任的线程在兄弟逻辑核心上运行。
- 当退出系统管理模式（使用
RSM指令）时，受 MDS 影响的缓冲区被覆盖。但是，在进入 SMM 模式时，SMM 软件必须确保没有不受信任的线程在同级逻辑内核上运行。
- 第 IX 节中的 RIDL论文提到“更新的微码在刷新 L1 缓存时也会刷新这些缓冲区。” 我认为这是指
IA32_FLUSH_CMDMSR，将索引 0 处的位设置为 1 会导致处理器回写并使整个 L1D 缓存无效。这被称为L1D_FLUSH命令。它还会覆盖所有易受 MDS 攻击的缓冲区。
以下处理器不易受到任何 MDS 攻击，但易受TAA攻击：
- 威士忌湖（仅限踏步 12 和 13）1 .
- 咖啡湖刷新（仅限第 13 步）。
- 第二代至强可扩展处理器（仅步进 6 和 7）。
类似的微码更新MD_CLEAR也适用于这些处理器以减轻 TAA。因此，VERW对这些处理器也有性能损失（根据 erratum CLX38，它是错误的）。
对于某些处理器，英特尔已经发布了多个版本的MD_CLEAR微码更新，以修复早期版本中的错误。
有些处理器容易受到 MDS 和 TAA 的攻击。其中包括 Coffee Lake Refresh（仅步进 10、11、12）、Whiskey Lake（仅步进 11）、第二代 Xeon 可扩展处理器（仅步进 5），以及更早的 Haswell（包括 Haswell）。在这些处理器上，MDS 缓解措施也适用于 TAA。有些处理器只容易受到 MDS 而不是 TAA 的影响，其中包括一些不支持 TSX 的处理器。
Ice Lake、Goldmont、Goldmont Plus、Tremont 处理器是唯一不受 MDS 和 TAA 影响并保留VERW.
在这篇英特尔文章中，在我看来，微码更新和操作系统补丁（使用VERW指令）对某些基准测试的性能影响非常显着（超过 5%）。最后还有一个常见问题列表，英特尔建议不要禁用 HT，这是有道理的。
RIDL 论文的 E 部分提到，作者能够从 MMU 的页面遍历硬件中泄漏物理地址（页面遍历通过 LFB）。我还没有看到针对此攻击的任何建议缓解措施。
最近的一些处理器包括针对所有四种 MDS 攻击的硬件缓解措施。这可以使用以下命令序列进行检查：
sudo modprobe msr
sudo rdmsr -p 0 0x10A
第一个命令加载msr内核模块，第二个命令读取IA32_ARCH_CAPABILITIESMSR 中的值。如果第六位（索引 5 处的位）为 1，则处理器具有针对所有 MDS 攻击的硬件缓解措施，因此不需要上面讨论的所有缓解措施。这个位被称为MDS_NO. 否则，处理器至少对 MSBDS、MLPDS 和 MDSUM 没有硬件缓解措施。请注意，如果IA32_ARCH_CAPABILITIES不支持 MSR 本身，那么处理器肯定没有针对所有 MDS 攻击的硬件缓解措施。
有关 MFBDS、MLPDS 和 MDSUM 如何工作的讨论，请参阅：关于 RIDL 漏洞和负载的“重放”。有关 MSBDS 工作原理的讨论，请参阅：MSBDS (Fallout) 背后的微架构细节是什么？.
脚注：
1我不知道有任何已发布的带有 step 13 的 Whiskey Lake 处理器。这可能是英特尔列表中的一个错误，也可能是英特尔决定不发布这些处理器。