缓解推测执行侧信道硬件漏洞

2018年1月3日，微软发布了关于新发现的硬件漏洞类别的公告和安全更新，这些漏洞涉及推测执行侧信道（称为Spectre和Meltdown），不同程度地影响AMD、ARM和Intel CPU。如果您尚未了解这些问题，我们建议观看BlueHat Israel上TU Graz团队的《The Case of Spectre and Meltdown》，阅读Google Project Zero的Jann Horn（@tehjh）的博客文章，或阅读Red Hat的Jon Masters在FOSDEM 2018上的演示。

这种新的硬件漏洞类别代表了CPU侧信道攻击的重大进展，我们衷心感谢发现这些问题的研究人员、行业合作伙伴以及微软内部许多致力于这些漏洞的人员。通过固件和软件更改来缓解硬件漏洞是一个重大的行业挑战，过去两个月用户对此存在一些困惑，因为行业集体继续努力解决这个问题。

在本文中，我们将深入探讨微软如何缓解推测执行侧信道硬件漏洞。我们将简要描述我们如何研究这个新的漏洞类别、建立的分类框架以及由此实施的缓解措施。本文主要面向对推测执行侧信道漏洞及其相应缓解措施的技术细节感兴趣的安全研究人员和工程师。如果您对更一般的指导感兴趣，请参阅我们的知识库文章，了解Windows Server、Windows Client和Microsoft云服务。

请注意，本文中的信息截至发布日期。

应对挑战

我们首先通过Google Project Zero的Jann Horn的发现了解到推测执行侧信道漏洞。鉴于这些攻击的潜在严重性和范围，我们启动了事件响应流程，以推动微软内部和行业合作伙伴的协调和修复。这最终动员了公司内部的数百人，但在此之前，我们需要评估问题的严重性、影响和根本原因。

传统的软件漏洞是众所周知的，并且相对容易进行根本原因分析（我们甚至在许多情况下有自动化工具，参见VulnScan）。而推测执行侧信道代表了一种全新的硬件漏洞类别，没有既定的流程来确定其严重性及其对现有软件安全模型的影响。为了创建这个流程，我们和行业内的其他人员需要彻底研究推测执行侧信道，并建立一个分类框架来推理其影响和可能的缓解措施。微软安全响应中心（MSRC）引入了微软内部的专家（例如微软研究剑桥和Windows进攻性安全研究团队），并聘请了GDATA高级分析的Anders Fogh（@anders_fogh）作为顾问，他在CPU侧信道攻击方面的深厚专业知识极大地促进了我们对这些问题的理解。这项研究为我们和其他人能够建立基础。

推测执行侧信道漏洞的框架

侧信道攻击包括三个阶段： priming阶段，用于将系统置于所需的初始状态（例如刷新缓存行）； triggering阶段，用于执行通过侧信道传递信息的操作；和 observing阶段，用于检测通过侧信道传递的信息的存在。这些阶段可以架构上发生（通过实际执行指令）或推测上发生（通过推测执行）。

涉及推测执行的侧信道攻击有四个组成部分： speculation primitive，提供进入非架构路径推测执行的手段； windowing gadget，提供足够的时间让推测执行通过侧信道传递信息； disclosure gadget，提供在推测执行期间通过侧信道通信信息的手段；和 disclosure primitive，提供读取由披露小工具通信的信息的手段。这四个组件可以以不同的方式组合来创建推测技术。

推测原语

Spectre和Meltdown使用了三种不同的推测原语。第一种是条件分支误预测（例如CVE-2017-5753，又名Variant 1），其中在预测条件分支是否被采取时可能发生推测。第二种是间接分支误预测（例如CVE-2017-5715，又名Variant 2），其中在预测间接分支（包括调用、跳转和返回）的目标时可能发生推测。第三种涉及异常传递或延迟（例如CVE-2017-5754，又名Variant 3），其中推测执行可能会继续越过将引发故障的点。这些原语中的每一个都可以用于沿着非架构路径进入推测执行，攻击者可以尝试以不同的方式触发推测（例如通过训练或碰撞预测器）。

窗口小工具

推测执行实际上是导致推测的µop（微操作）的退休与推测执行的µop之间的竞争条件。攻击者必须赢得这个竞争条件，披露小工具才能推测执行。我们定义了三种窗口小工具类别。第一种涉及非缓存加载，触发从主内存加载，这通常在大多数CPU上需要数百个周期。第二种涉及加载的依赖链，其中可能包括非缓存加载。第三种涉及整数ALU操作的依赖链，这些操作具有固定延迟操作。这些窗口小工具可以自然出现在代码中，或者在某些情况下由攻击者制造。

披露小工具

在侧信道攻击的背景下，推测执行的主要目的是触发披露小工具的执行。这是因为披露小工具负责访问存储在安全域中的信息，这些信息在架构上对攻击者不可见，并通过侧信道传递该信息。这可能包括内存内容、寄存器状态等。与返回导向编程（ROP）中使用的小工具一样，披露小工具有许多可能的例子，其形式和功能会有所不同。

披露原语

在推测执行披露小工具通过侧信道传递信息后，最后一步是使用披露原语检测该信息的存在。每个披露原语本质上与信息传递的通信通道（例如CPU数据缓存等）以及披露小工具传递信息的方式相关联。对于其他侧信道，如FLUSH+RELOAD和PRIME+PROBE，已有大量先前研究。这些原语通常也适用于推测执行侧信道。

与软件安全模型的相关性

现代操作系统和应用程序依赖于在设备上隔离本机代码的软件安全模型。这些安全模型包括基于虚拟化的隔离、内核/用户分离、基于进程的隔离和基于语言的隔离（例如JavaScript运行时沙箱）等概念。这些安全模型的设计强烈依赖于底层硬件保证，即分配给一个安全域的内存不能被另一个安全域读取或写入，除非由特权仲裁者（如虚拟机监控程序、内核或托管运行时）允许。这是由硬件和操作系统通过特权模式（虚拟机监控程序、内核、用户）、分页等概念强制执行的。不幸的是，推测执行侧信道漏洞可能使得跨安全域读取内存成为可能，从而违反现有的软件安全模型。

为了说明这一点，下表总结了推测原语与代表关注软件安全模型的攻击场景的相关性。每个攻击场景都描述了执行推测执行侧信道攻击时信息流的方向。橙色单元格表示推测原语适用于相应的攻击场景，而灰色单元格不适用。

虚拟机间

此类别涉及对基于虚拟化的隔离的攻击，该隔离依赖于硬件对虚拟化扩展的支持以实现安全。虚拟机监控程序到客户机攻击涉及恶意客户机尝试读取虚拟机监控程序内存。主机到客户机攻击涉及恶意客户机读取提供虚拟化辅助的特权客户机内存（例如Hyper-V中的根分区或Xen中的dom0）。客户机到客户机攻击涉及恶意客户机读取另一个客户机的内存。

操作系统内

此类别涉及传统操作系统实例（例如VM中的OS或物理设备上的OS）内的攻击。内核到用户攻击涉及恶意用户模式进程读取内核内存。进程到进程攻击涉及恶意用户模式进程读取另一个不应可读的进程的内存。进程内攻击涉及强制进程读取其自己的内存，例如网站向Web浏览器提供JavaScript，然后创建推测执行侧信道漏洞的条件。

enclave

enclave类别涉及enclave到任意攻击，其中在enclave外部执行的代码（例如Intel SGX enclave）能够读取enclave内的内存。

推测执行侧信道漏洞的缓解措施

上述分类框架为定义缓解推测执行侧信道漏洞的策略和一组战术提供了基础。通过这个过程，我们确定了软件（和硬件）可以采用的三种通用战术，以不同程度的完整性缓解此问题。这些战术总结在下表中：

在以下部分中，我们将描述我们实施的缓解措施及其对迄今为止描述的推测技术的影响。

防止推测技术

缓解漏洞的最佳方法之一是在根本原因上消除一类问题。对于推测执行攻击，这可以通过防止推测原语用于执行所需的披露小工具来实现。

通过执行序列化指令的推测屏障

这种缓解涉及插入通过序列化执行充当推测屏障的指令。在AMD和Intel CPU上，这涉及使用LFENCE指令，而ARM建议使用条件选择/移动（CSEL/MOVS）指令以及新的显式屏障指令（CSDB）。微软已向Visual C++添加了对/Qspectre标志的支持，该标志目前启用一些狭窄的编译时静态分析，以识别与CVE-2017-5753相关的风险代码序列并插入推测屏障指令。此标志已用于重建Windows中的风险代码，并随我们2018年1月的安全更新发布。但重要的是要注意，Visual C++编译器无法保证CVE-2017-5753的完全覆盖，这意味着此漏洞的实例可能仍然存在。我们建议软件开发人员将CVE-2017-5753视为一个新的硬件漏洞类别，可以通过添加显式推测屏障在软件中缓解。虽然我们继续寻找改进Visual C++对/Qspectre支持的机会，但微软还宣布了一个推测执行侧信道赏金计划，以鼓励研究人员查找和报告任何可能剩余的CVE-2017-5753实例。

类似地，Microsoft Edge和Internet Explorer中的JavaScript即时（JIT）编译器包括对CVE-2017-5753的代码生成缓解措施。这些缓解措施限制了与CVE-2017-5753相关的推测执行对JIT生成的动态生成本机代码的允许行为。

安全域CPU核心隔离

现代CPU通常在每个核心或每个SMT缓存中存储预测状态。这意味着将工作负载隔离到不同的核心可以用于稳健地缓解依赖于碰撞预测状态的推测技术。为此，微软发布了文档，描述了如何使用最小根（“minroot”）将核心专用于Hyper-V根分区，以及如何使用CPU组将核心专用于客户机。

按需和模式更改的间接分支推测屏障

依赖于一个安全域（用户、内核、虚拟机监控程序）能够影响另一个安全域中的间接分支预测（例如CVE-2017-5715）的推测技术可以通过使用Intel、AMD和ARM提供的额外硬件接口来缓解。在Intel和AMD的情况下，这些硬件接口需要微码更新以暴露操作系统可以利用的功能。这些功能使软件能够刷新间接分支预测状态、抑制使用来自较低特权安全域的分支预测，并防止兄弟硬件线程预测干扰。Intel和AMD的微码更新目前处于不同的准备和可用性水平，但通常预计能够为跨安全域使用间接分支误预测的推测技术启用强缓解措施。2018年3月1日，微软宣布通过Microsoft更新目录（KB4090007）提供Intel微码更新。

非推测或安全推测的间接分支

现有Intel和AMD硬件上的某些类型的间接分支要么根本不预测，要么具有通常安全的预测行为，因此可以用于缓解CVE-2017-5715。例如，现有Intel硬件上的远JMP不被预测，因此可以用作近间接CALL和JMP的替代方案。这种缓解利用远JMP行为，通过在Intel硬件上运行时将所有有风险的间接CALL和JMP指令转换为远JMP来为Hyper-V虚拟机监控程序实现。对于在AMD硬件上运行的Hyper-V虚拟机监控程序，有风险的近间接CALL和JMP前面按照AMD的推荐指南添加执行序列化RDTSCP指令。

类似地，Google还提出了一个称为retpoline的软件解决方案，将近间接调用和跳转转换为“retpolines”，这些retpolines在传输控制时依赖于安全且确定的近返回误预测。该解决方案为在许多现有CPU上使用间接分支误预测的推测技术提供了强缓解措施。我们认为retpoline可以适用于重建所有风险代码的环境，并且我们通过对Hyper-V所做的更改追求了类似的路径。我们还在评估涉及Windows内核和设备驱动程序的混合缓解的性能优化，这将涉及retpoline和硬件对间接分支推测屏障的支持。

关于使用retpoline，有一些额外的要点需要考虑。正如Intel所指出的，一些现代CPU不满足retpoline所依赖的近返回预测的安全属性，而不要求软件防止RSB（返回堆栈缓冲区）下溢。这些CPU要求软件执行RSB填充以防止下溢，我们认为在一般情况下软件执行此操作并非易事。此外，需要重建所有风险软件的场景在广泛、多供应商、二进制生态系统（如多租户云环境或使用由多个供应商生产的应用程序和其他软件的传统桌面和服务器）中面临重大挑战。对于这些环境，我们认为期望所有风险软件都被重建是不合理的。展望未来，硬件安全改进（如Intel的控制流执行技术（CET））将遇到与使用retpoline的兼容性问题，软件开发人员需要考虑。

从内存中删除敏感内容

所有涉及推测执行侧信道的攻击都试图跨安全域获取信息。这意味着攻击者将尝试披露他们不应访问的受害者安全域中的数据。因此，从受害者安全域中删除敏感信息可以是防止使用推测技术的信息披露的有效方法。

虚拟机监控程序地址空间隔离

Microsoft Hyper-V虚拟机监控程序历史上维护所有物理内存的标识映射，以加速在虚拟机监控程序中执行时的内存访问（称为“物理映射”）。为了最小化对推测技术的暴露，我们完全移除了物理映射，不再将所有物理内存映射到虚拟机监控程序的地址空间，从而有助于缓解通过推测执行进行跨VM信息披露的风险。

分离用户和内核页表

这种缓解在Windows上称为内核虚拟地址（KVA）Shadow，它通过为每个进程创建两个页目录基来缓解称为Meltdown（CVE-2017-5754）的推测技术。第一个映射“用户”页表，仅包含用户模式映射和少量内核转换页。第二个映射“内核”页表，包含进程的用户和内核映射。用户页表在用户模式下执行代码时处于活动状态，而内核页在代表进程陷入和执行内核模式代码时切换到。这具有从进程的虚拟地址空间中移除敏感内核内存内容的效果，从而为CVE-2017-5754提供稳健的缓解。这种缓解借鉴了先前称为KAISER的研究，尽管KVA Shadow并非旨在启用稳健的本地内核ASLR（KASLR）。KVA Shadow也类似于可用于Linux内核（内核页表隔离，KPTI）、Apple MacOS和iOS以及Google Chromebook的缓解措施。

移除观察通道

所有推测技术都隐式依赖于通过侧信道通信信息，其方式可以被披露原语检测到。这意味着推测技术可以通过移除通信和观察信息的通道来广泛缓解。

在根扩展页表中将客户机内存映射为不可缓存

虚拟化软件通常将客户机内存映射到特权客户机（Hyper-V的“根”或Xen的dom0）的地址空间中，以通过共享内存实现快速通信。在推测技术的背景下，这些共享内存区域可用于通过加载共享缓存行（例如FLUSH+RELOAD）来通信信息。一种缓解方法是在根的扩展页表中将客户机内存区域映射为不可缓存（UC）。在所有CPU上，不可缓存内存无法在推测执行期间加载，因此防止了共享缓存行的加载。

不在客户机之间共享物理页

在某些情况下，虚拟化软件可能在客户机之间共享物理页。这些共享内存区域可用于通过加载共享缓存行（类似于将客户机内存映射为不可缓存）来通信信息。在这种情况下，这些共享区域可以促进涉及推测执行的客户机到客户机攻击。这种缓解实现了直接的解决方案，即停止在不属于同一安全域的客户机之间共享物理页。

降低浏览器计时器精度

进程内攻击场景与Web浏览场景相关，其中网站提供的JavaScript可能诱导JavaScript JIT创建本机代码，该代码表现出推测执行侧信道漏洞，如CVE-2017-5753。为了帮助缓解此问题，Microsoft Edge和Internet Explorer已更新以减少Web浏览器暴露的计时器的精度。这增加了以高带宽披露信息的难度。

缓解措施的适用性

这些问题的复杂性使得难以理解缓解措施、推测技术及其适用的攻击场景之间的关系。

以下表格的图例：

• ✅ 适用
• ❌ 不适用

缓解措施与攻击场景的关系

下表总结了攻击场景与适用缓解措施之间的关系。

缓解措施与变种的关系

下表总结了Spectre和Meltdown变种与适用缓解措施之间的关系。

总结

在本文中，我们描述了缓解涉及推测执行侧信道的新硬件漏洞类别的方法。我们相信本文中描述的缓解措施为这些漏洞提供了强有力的保护。展望未来，我们建议软件行业将这些问题视为一个新的漏洞类别，可能需要软件更改来帮助缓解（例如像缓冲区溢出、类型混淆、释放后使用等）。我们预计这个新的硬件漏洞类别将成为进一步研究的主题，正如我们过去与其他漏洞类别所见证的那样。微软致力于保护我们的客户，我们将继续与行业合作伙伴合作缓解推测执行侧信道漏洞。为了加强这一承诺，我们启动了推测执行侧信道赏金计划，以鼓励发现和报告这些漏洞，以便修复它们。

Matt Miller，微软安全响应中心（MSRC）