分析与缓解L1终端故障（L1TF）

作者：swiat
发布日期：2018年8月13日
阅读时间：13分钟

2018年1月，微软发布了一份公告和安全更新，针对一类涉及推测执行侧信道的新硬件漏洞（称为Spectre和Meltdown）。在本博客文章中，我们将对一种新的推测执行侧信道漏洞进行技术分析，该漏洞被称为L1终端故障（L1TF），并分配了CVE-2018-3615（用于SGX）、CVE-2018-3620（用于操作系统和SMM）和CVE-2018-3646（用于虚拟化）。此漏洞影响Intel Core处理器和Intel Xeon处理器。

本文主要面向对L1TF技术分析及相关缓解措施感兴趣的安全研究人员和工程师。如果您需要更一般的指导，请参考微软的L1TF安全公告。

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

L1终端故障（L1TF）概述

我们之前定义了四类推测原语，可用于创建推测执行侧信道的条件。每类原语提供了一种进入非架构路径推测执行的基本方法，具体包括：条件分支误预测、间接分支误预测、异常传递或延迟以及内存访问误预测。L1TF属于异常传递或延迟类别的推测原语（与Meltdown和Lazy FP状态恢复一起），因为它处理与生成架构异常的逻辑相关的推测（或乱序）执行。在本文中，我们将提供L1TF的一般总结。如需更深入的分析，请参考Intel为此漏洞发布的公告和白皮书。

L1TF的出现是由于CPU在处理地址转换时执行页表遍历的优化。在转换线性地址时，CPU可能会遇到终端页故障，当虚拟地址的页表条目不存在（Present位为0）或其他无效时会发生这种情况。这将导致异常，例如页故障或TSX事务中止，沿架构路径发生。然而，在这些发生之前，易受L1TF影响的CPU可能会为正在转换的线性地址从L1数据缓存启动读取。对于这种仅推测的读取，终端（不存在）页表条目的页帧位被视为系统物理地址，即使是客户页表条目也是如此。如果该物理地址的缓存行存在于L1数据缓存中，则该行的数据可能会转发到依赖操作，这些操作可能在导致终端页故障的指令退休之前推测执行。与L1TF相关的行为可能发生在涉及常规页表和扩展页表（后者用于虚拟化）的页表遍历中。

为了说明这可能如何发生，考虑以下简化示例可能会有所帮助。在此示例中，攻击者控制的虚拟机（VM）在VM内构建了一个页表层次结构，目标是读取所需的系统（主机）物理地址。下图提供了虚拟地址0x12345000的示例层次结构，其中终端页表条目不存在但包含页帧0x9a0，如下所示：

[图表描述虚拟地址0x12345000的页表层次结构，终端PTE不存在且页帧为0x9a0]

设置此层次结构后，VM可以尝试通过以下指令序列从系统物理地址[0x9a0000, 0x9a1000)读取：

1
2
3

01: 4C0FB600          movzx r8,byte [rax] ; rax = 0x12345040
02: 49C1E00C          shl r8,byte 0xc
03: 428B0402          mov eax,[rdx+r8]    ; rdx = signal数组的地址

通过在TSX事务中执行这些指令或通过处理架构页故障，VM可以尝试从与系统物理地址0x9a0040相关的L1数据缓存行（如果在L1中）诱导推测加载，并将该缓存行的第一个字节转发到使用此字节作为信号数组偏移的乱序加载。这将为使用FLUSH+RELOAD等披露原语观察字节值创造条件，从而在系统物理地址未分配给VM的情况下导致跨安全边界的信息披露。

虽然上述场景说明了L1TF如何应用于推断虚拟机边界上的物理内存（VM完全控制客户页表），但L1TF也可能在其他场景中被利用。例如，用户模式应用程序可以尝试使用L1TF从其地址空间内不存在终端页表条目引用的物理地址读取。实际上，操作系统通常使用不存在页表条目格式中的软件位来存储元数据，这可能等同于有效的物理页帧。这可能允许进程读取未分配给进程（或在虚拟化场景中的VM）的物理内存，或进程内不打算可访问的内存（例如Windows上的PAGE_NOACCESS内存）。

L1终端故障（L1TF）的缓解措施

L1TF有多种缓解措施，它们根据被缓解的攻击类别而有所不同。为了说明这一点，我们将描述面临L1TF风险的软件安全模型以及可用于缓解它的具体策略。我们将重用之前关于缓解推测执行侧信道的文章中的缓解分类法。在许多情况下，本节描述的缓解措施需要结合使用，以提供对L1TF的广泛防御。

与软件安全模型的相关性

下表总结了L1TF与软件安全模型通常关注的各种设备内攻击场景的潜在相关性。与仅影响内核到用户场景的Meltdown（CVE-2017-5754）不同，L1TF适用于所有设备内攻击场景，如橙色单元格所示（灰色单元格表示不适用）。这是因为L1TF可能提供读取任意系统物理内存的能力。

防止涉及L1TF的推测技术

正如我们过去所指出的，缓解漏洞的最佳方法之一是尽可能接近根本原因解决问题。对于L1TF，有多种缓解措施可用于防止涉及L1TF的推测技术。

不存在页表条目中的安全页帧位

涉及L1TF的攻击的要求之一是终端页表条目的页帧位必须引用包含来自另一个安全域的敏感数据的有效物理页。这意味着兼容的管理程序和操作系统内核可以通过确保以下之一来缓解L1TF的某些攻击场景：1）不存在页表条目的页帧位引用的物理页始终包含良性数据；和/或2）在页帧位中设置一个高位，该位不对应于可访问的物理内存。对于#2，Windows内核将使用小于给定处理器支持的已实现物理地址位的位，以避免物理地址截断（例如，丢弃高位）。

从2018年8月的Windows安全更新开始，所有受支持的Windows内核和Hyper-V管理程序版本确保在易受L1TF影响的硬件上自动强制执行#1和#2。这对于常规页表条目和扩展页表条目（不存在）都强制执行。在Windows Server上，此缓解措施默认禁用，必须按照我们发布的Windows Server指南启用。

为了说明这是如何工作的，考虑以下用户模式虚拟地址的示例，该地址不可访问，因此具有不存在的PTE。在此示例中，页帧位仍然引用可能被解释为与L1TF结合的有效物理地址：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

26: kd> !pte 0x00000281`d84c0000
…   PTE at FFFFB30140EC2600
…   contains 0000000356CDEB00
…   not valid
…    Transition: 356cde
…    Protect: 18 - No Access

26: kd> dt nt!HARDWARE_PTE FFFFB30140EC2600
+0x000 Valid : 0y0
+0x000 Write : 0y0
+0x000 Owner : 0y0
+0x000 WriteThrough : 0y0
+0x000 CacheDisable : 0y0
+0x000 Accessed : 0y0
+0x000 Dirty : 0y0
+0x000 LargePage : 0y0
+0x000 Global : 0y1
+0x000 CopyOnWrite : 0y1
+0x000 Prototype : 0y0
+0x000 reserved0 : 0y1
+0x000 PageFrameNumber : 0y000000000000001101010110110011011110 (0x356cde)
+0x000 reserved1 : 0y0000
+0x000 SoftwareWsIndex : 0y00000000000 (0)
+0x000 NoExecute : 0y0

应用2018年8月的Windows安全更新后，可以观察到在不存在页表条目中设置高位的行为，该位引用不可访问或保证为良性的物理内存（在此情况下为位45）。由于这不对应于可访问的物理地址，任何尝试使用L1TF从中读取的操作都将失败。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

17: kd> !pte  0x00000196`04840000
…   PTE at FFFF8000CB024200
…   contains 0000200129CB2B00
…   not valid
…    Transition: 200129cb2
…    Protect: 18 - No Access

17: kd> dt nt!HARDWARE_PTE FFFF8000CB024200
+0x000 Valid            : 0y0
+0x000 Write            : 0y0
+0x000 Owner            : 0y0
+0x000 WriteThrough     : 0y0
+0x000 CacheDisable     : 0y0
+0x000 Accessed         : 0y0
+0x000 Dirty            : 0y0
+0x000 LargePage        : 0y0
+0x000 Global           : 0y1
+0x000 CopyOnWrite      : 0y1
+0x000 Prototype        : 0y0
+0x000 reserved0        : 0y1
+0x000 PageFrameNumber  : 0y001000000000000100101001110010110010 (0x200129cb2)
+0x000 reserved1        : 0y0000
+0x000 SoftwareWsIndex  : 0y00000000000 (0)
+0x000 NoExecute        : 0y0

为了提供一种可移植的方法，允许VM确定系统支持的已实现物理地址位，Hyper-V管理程序顶级功能规范（TLFS）已修订，定义了一个接口，VM可以使用该接口查询此信息。这有助于在迁移池中安全迁移虚拟机。

在安全域转换时刷新L1数据缓存

通过使用L1TF披露信息需要受害者安全域的敏感数据存在于L1数据缓存中（注意，L1D由同一物理核心上的所有LP共享）。这意味着可以通过在安全域之间转换时刷新L1数据缓存来防止披露。为了促进这一点，Intel通过微码更新提供了新功能，支持刷新L1数据缓存的架构接口。

从2018年8月的Windows安全更新开始，Hyper-V管理程序现在使用新的L1数据缓存刷新功能（如果存在）以确保在关键点从L1数据缓存中删除VM数据。在Windows Server 2016+和Windows 10 1607+上，刷新在VM之间切换虚拟处理器上下文时发生。这通过最小化需要发生的次数来帮助减少刷新的性能影响。在早期版本的Windows上，刷新在执行VM之前发生（例如，在VMENTRY之前）。

为了使Hyper-V管理程序中的L1数据缓存刷新健壮，刷新与安全使用或禁用超线程以及每个虚拟处理器管理程序地址空间结合执行。

对于SGX enclave场景，Intel提供的微码更新确保逻辑处理器退出enclave执行模式时刷新L1数据缓存。微码更新还支持证明BIOS是否启用了HT。当HT启用时，在L1数据缓存中的enclave秘密被刷新或清除之前，存在来自兄弟逻辑处理器的L1TF攻击的可能性。验证证明的实体如果认为来自兄弟逻辑处理器的L1TF攻击风险不可接受，可能会拒绝来自HT启用系统的证明。

兄弟逻辑处理器的安全调度

Intel的超线程（HT）技术，也称为同时多线程（SMT），允许多个逻辑处理器（LP）在物理核心上同时执行。每个兄弟LP可以同时在不同安全域和特权模式下执行代码。例如，一个LP可能在管理程序中执行，而另一个在VM内执行代码。这对L1数据缓存刷新有影响，因为敏感数据可能在L1数据缓存刷新发生后通过兄弟LP重新进入L1数据缓存。

为了防止这种情况发生，兄弟LP上的代码执行必须安全调度或必须禁用HT。这两种方法都确保核心的L1数据缓存不会在刷新发生后被来自另一个安全域的数据污染。

Windows Server 2016及更高版本上的Hyper-V管理程序支持称为核心调度器的功能，确保在物理核心上执行的虚拟处理器始终属于同一VM，并被描述为VM的兄弟超线程。此功能在Windows Server 2016上需要管理员选择加入，并从Windows Server 2019开始默认启用。这与每个虚拟处理器管理程序地址空间结合，使得可以将L1数据缓存刷新推迟到核心开始执行来自不同VM的虚拟处理器时，而不是需要在每次VMENTRY时执行刷新。有关如何在Hyper-V中实现此功能的更多详细信息，请参阅关于此主题的深入Hyper-V技术博客。

下图说明了具有两个不同VM（VM 1和VM 2）的场景中虚拟处理器调度策略的差异。如图所示，未启用核心调度时，来自两个不同VM的代码可能同时在核心上执行（在此情况下为核心2），而启用核心调度后这是不可能的。

[图表显示启用和未启用核心调度时VM调度差异]

在Windows Server 2016之前的Windows版本以及所有启用虚拟化的Windows客户端版本上，不支持核心调度器功能，因此可能需要禁用HT以确保L1数据缓存刷新对于VM间隔离的健壮性。这在Windows Server 2016+上对于使用虚拟安全模式（VSM）隔离秘密的场景也是当前必要的。当HT禁用时，兄弟逻辑处理器不可能在同一物理核心上同时执行。有关如何在Windows上禁用HT的指导，请参考我们的公告。

从内存中删除敏感内容

另一种缓解推测执行侧信道的策略是从地址空间中删除敏感内容，使其无法通过推测执行披露。

每个虚拟处理器地址空间

在推测执行侧信道出现之前，管理程序没有强烈需要按VM分区其虚拟地址空间。因此，管理程序维护所有物理内存的虚拟映射以简化内存访问是常见做法。L1TF和其他推测执行侧信道的存在使得在管理程序代表VM操作时，从管理程序的虚拟地址空间中消除跨VM秘密变得可取。

从2018年8月的安全更新开始，Windows Server 2016+和Windows 10 1607+中的Hyper-V管理程序现在使用每个虚拟处理器（因此每个VM）地址空间，并且不再将所有物理内存映射到管理程序的虚拟地址空间中。这确保只有分配给VM和管理程序代表VM的内存可能在给定虚拟处理器的推测期间可访问。对于L1TF，此缓解措施与L1数据缓存刷新以及安全使用或禁用HT结合使用，以确保没有敏感的跨VM信息在L1中可用。

缓解适用性

前面章节描述的缓解措施结合使用，为L1TF提供广泛保护。下表总结了攻击场景以及不同版本Windows Server和Windows客户端的相关缓解措施和默认设置：

更简洁地，L1TF的攻击场景与缓解措施之间的关系总结如下：

总结

在本文中，我们分析了一种新的推测执行侧信道漏洞，称为L1终端故障（L1TF）。此漏洞影响广泛的攻击场景，相关缓解措施需要为受影响的Intel处理器系统结合软件和固件（微码）更新。L1TF的发现表明，对推测执行侧信道的研究正在进行中，我们将继续相应地发展我们的响应和缓解策略。我们继续鼓励研究人员通过我们的推测执行侧信道赏金计划报告新发现。

Matt Miller
Microsoft安全响应中心（MSRC）