L1TF - L1 终端故障

L1 终端故障是一种硬件漏洞,当控制虚拟地址(用于访问)的页表项的 Present 位被清除或设置了其他保留位时,该漏洞允许非特权推测性地访问一级数据缓存中可用的数据。

受影响的处理器

此漏洞影响范围广泛的 Intel 处理器。此漏洞不存在于

  • 来自 AMD、Centaur 和其他非 Intel 供应商的处理器

  • CPU 系列小于 6 的较旧处理器型号

  • 一系列 Intel ATOM 处理器 (Cedarview, Cloverview, Lincroft, Penwell, Pineview, Silvermont, Airmont, Merrifield)

  • Intel XEON PHI 系列

  • IA32_ARCH_CAPABILITIES MSR 中设置了 ARCH_CAP_RDCL_NO 位的 Intel 处理器。如果设置了该位,则 CPU 也不受 Meltdown 漏洞的影响。这些 CPU 应在 2018 年底前上市。

处理器是否受影响可以从 sysfs 中的 L1TF 漏洞文件中读取。参见 L1TF 系统信息

问题

如果一条指令访问了一个虚拟地址,而该地址相关的页表项 (PTE) 的 Present 位已被清除或设置了其他保留位,那么推测性执行会忽略该无效 PTE,并加载一级数据缓存中存在的引用数据,就像 PTE 中地址位引用的页面仍然存在且可访问一样。

尽管这纯粹是一种推测性机制,并且指令最终在退役时会引发页错误,但加载数据并使其可供其他推测性指令使用的纯粹行为,为非特权恶意代码的侧信道攻击打开了机会,类似于 Meltdown 攻击。

尽管 Meltdown 破坏了用户空间到内核空间的保护,但 L1TF 允许攻击系统中任何物理内存地址,并且攻击适用于所有保护域。它允许攻击 SGX,并且从虚拟机内部也能奏效,因为推测会绕过扩展页表 (EPT) 保护机制。

攻击场景

1. 恶意用户空间

操作系统将任意信息存储在标记为不存在的 PTE 的地址位中。这使得恶意用户空间应用程序能够攻击这些 PTE 解析到的物理内存。在某些情况下,用户空间可以恶意影响 PTE 地址位中编码的信息,从而使攻击更具确定性和实用性。

Linux 内核包含针对此攻击向量的缓解措施——PTE 反转,该措施永久启用且不影响性能。内核确保未标记为 Present 的 PTE 的地址位永远不会指向可缓存的物理内存空间。

具有最新内核的系统受到保护,可抵御来自恶意用户空间应用程序的攻击。

2. 虚拟机中的恶意访客

L1TF 破坏所有域保护的事实允许能够直接控制 PTE 的恶意访客操作系统以及运行在缺少 L1TF PTE 反转缓解措施的未受保护访客内核上的恶意访客用户空间应用程序攻击物理主机内存。

在虚拟化背景下,L1TF 的一个特殊方面是对称多线程 (SMT)。Intel 对 SMT 的实现称为超线程 (HyperThreading)。受影响处理器上的超线程共享 L1 数据缓存 (L1D) 这一点很重要。由于该缺陷只允许攻击 L1D 中存在的数据,因此运行在一个超线程上的恶意访客可以攻击由同一物理核心的兄弟超线程上运行的上下文带入 L1D 的数据。此上下文可以是主机操作系统、主机用户空间或不同的访客。

如果处理器不支持扩展页表,则只有在虚拟机监控程序不清理有效(影子)页表内容的情况下才可能发生攻击。

尽管存在完全缓解这些攻击向量的解决方案,但 Linux 内核中默认不启用这些缓解措施,因为它们会显著影响性能。内核提供了多种机制,可以根据部署场景来利用这些机制解决问题。缓解措施、其保护范围和影响将在后续章节中描述。

默认缓解措施及其选择理由在本文件末尾解释。参见 默认缓解措施

L1TF 系统信息

Linux 内核提供了一个 sysfs 接口来枚举系统的当前 L1TF 状态:系统是否脆弱,以及哪些缓解措施处于活动状态。相关 sysfs 文件是

/sys/devices/system/cpu/vulnerabilities/l1tf

此文件中可能的值是

‘未受影响’

处理器不受影响

‘缓解:PTE 反转’

主机保护已激活

如果启用了 KVM/VMX 且处理器存在漏洞,则以下信息将附加到“缓解:PTE 反转”部分

  • SMT 状态

    ‘VMX: SMT 易受攻击’

    SMT 已启用

    ‘VMX: SMT 已禁用’

    SMT 已禁用

  • L1D 刷新模式

    ‘L1D 易受攻击’

    L1D 刷新已禁用

    ‘L1D 条件性缓存刷新’

    L1D 刷新条件性启用

    ‘L1D 缓存刷新’

    L1D 刷新无条件启用

最终的保护等级将在以下章节中讨论。

主机缓解机制

内核无条件地受到保护,可抵御来自主机上运行的恶意用户空间的 L1TF 攻击。

访客缓解机制

1. VMENTER 上的 L1D 刷新

为了确保访客无法攻击 L1D 中存在的数据,虚拟机监控程序在进入访客之前刷新 L1D。

刷新 L1D 不仅驱逐了潜在恶意访客不应访问的数据,还会刷新访客数据。刷新 L1D 会影响性能,因为处理器必须将已刷新的访客数据重新带回 L1D。根据 VMEXIT/VMENTER 的频率和访客中的计算类型,已观察到 1% 到 50% 的性能下降。对于访客 VMEXIT/VMENTER 很少见的场景,性能影响最小。Virtio 和诸如发布中断之类的机制旨在将 VMEXIT 限制在最低限度,但特定配置和应用场景仍可能遭受高 VMEXIT 率的影响。

内核提供两种 L1D 刷新模式
  • 条件性(‘cond’)

  • 无条件性(‘always’)

条件模式避免了在相应的 VMENTER 之前仅执行经过审计的代码路径的 VMEXIT 后刷新 L1D。这些代码路径已经过验证,它们不会向攻击者暴露秘密或其他有趣数据,但它们可能会泄露有关虚拟机监控程序地址空间布局的信息。

无条件模式在所有 VMENTER 调用上刷新 L1D 并提供最大保护。它的开销高于条件模式。由于开销取决于工作负载场景和产生的 VMEXIT 数量,因此无法准确量化。

一般建议是在 VMENTER 上启用 L1D 刷新。内核在受影响的处理器上默认为条件模式。

注意,L1D 刷新并不能阻止 SMT 问题,因为兄弟线程也会将其数据带回 L1D,从而使其再次受到攻击。

管理员可以通过内核命令行和 sysfs 控制文件控制 L1D 刷新。参见 内核命令行上的缓解控制KVM 缓解控制 - 模块参数

2. 访客 VCPU 限制到专用物理核心

为了解决 SMT 问题,可以将一个或一组访客关联到一个或多个物理核心。适当的机制是利用排他性 CPU 集 (cpusets) 来确保没有其他访客或主机任务可以在这些核心上运行。

如果只有一个访客或相关访客在同一物理核心的兄弟 SMT 线程上运行,那么他们只能攻击自己的内存和主机内存的受限部分。

当一个兄弟 SMT 线程在主机操作系统(虚拟机监控程序)上下文中运行,而另一个在访客上下文中运行时,主机内存是可被攻击的。来自主机操作系统上下文的有价值信息量取决于主机操作系统执行的上下文,即中断、软中断和内核线程。除非对代码进行深入检查,否则无法声明来自这些上下文的有价值数据对攻击者不感兴趣。

注意,将访客分配到一组固定的物理核心会影响调度器进行负载均衡的能力,并可能根据托管场景对 CPU 利用率产生负面影响。禁用 SMT 对于特定场景可能是一个可行的替代方案。

有关将访客限制到单个或一组核心的更多信息,请查阅 cpusets 文档

https://linuxkernel.org.cn/doc/Documentation/admin-guide/cgroup-v1/cpusets.rst

3. 中断亲和性

中断可以与逻辑 CPU 关联。这并非普遍适用,因为有些中断确实是每个 CPU 中断,例如本地计时器中断。除此之外,多队列设备会将其中断关联到每个队列的单个 CPU 或 CPU 组,而不允许管理员控制这些关联。

将可亲和性控制的中断从运行不受信任访客的 CPU 移开,可以减少攻击向量空间。

与运行不受信任访客的 CPU 亲和的中断是否为攻击者提供有趣数据取决于系统配置和在系统上运行的场景。尽管对于某些中断可以假定它们不会暴露除主机操作系统内存布局提示之外的有趣信息,但无法做出一般性假设。

管理员可以通过 /proc/irq/$NR/smp_affinity[_list] 文件控制中断亲和性。有限的文档可在以下地址找到

https://linuxkernel.org.cn/doc/Documentation/core-api/irq/irq-affinity.rst

4. SMT 控制

为防止 L1TF 的 SMT 问题,可能需要完全禁用 SMT。禁用 SMT 可能会对性能产生显著影响,但其影响取决于托管场景和工作负载类型。禁用 SMT 的影响还需要与限制访客到专用核心等其他缓解解决方案的影响进行权衡。

内核提供了一个 sysfs 接口来检索 SMT 状态并控制它。它还提供了一个内核命令行接口来控制 SMT。

内核命令行接口包含以下选项

nosmt

影响引导期间辅助 CPU 的启动。内核在引导过程中尝试使所有存在的 CPU 上线。“nosmt”确保每个物理核心只有一个所谓的原主(超)线程被激活。由于 Intel 处理器与机器检查异常相关的设计缺陷,非原主兄弟线程必须至少部分启动,然后再次关闭。“nosmt”可以通过 sysfs 接口撤销。

nosmt=force

效果与“nosmt”相同,但不允许通过 sysfs 接口撤销 SMT 禁用。

sysfs 接口提供两个文件

  • /sys/devices/system/cpu/smt/control

  • /sys/devices/system/cpu/smt/active

/sys/devices/system/cpu/smt/control

此文件允许读取 SMT 控制状态,并提供禁用或(重新)启用 SMT 的能力。可能的状态是

开启

CPU 支持 SMT 并已启用。所有逻辑 CPU 都可以不受限制地上线和下线。

关闭

CPU 支持 SMT 并已禁用。只有所谓的原主 SMT 线程可以不受限制地上线和下线。尝试使非原主兄弟线程上线将被拒绝

强制关闭

与“off”相同,但状态无法控制。写入控制文件的尝试将被拒绝。

不支持

处理器不支持 SMT。因此它不受 L1TF SMT 影响。写入控制文件的尝试将被拒绝。

可以写入此文件以控制 SMT 状态的可能状态是

  • 开启

  • 关闭

  • 强制关闭

/sys/devices/system/cpu/smt/active

此文件报告 SMT 是否已启用并处于活动状态,即任何物理核心上是否有两个或更多兄弟线程在线。

SMT 控制也可以在引导时通过 l1tf 内核命令行参数结合 L1D 刷新控制来实现。参见 内核命令行上的缓解控制

5. 禁用 EPT

即使启用了 SMT,为虚拟机禁用 EPT 也能为 L1TF 提供全面的缓解,因为访客的有效页表由虚拟机监控程序管理和清理。尽管禁用 EPT 会对性能产生显著影响,尤其是在启用了 Meltdown 缓解措施 KPTI 时。

EPT 可以在虚拟机监控程序中通过“kvm-intel.ept”参数禁用。

目前正在进行新的缓解机制的研究和开发,以解决禁用 SMT 或 EPT 带来的性能影响。

内核命令行上的缓解控制

内核命令行允许在引导时使用选项“l1tf=”控制 L1TF 缓解措施。此选项的有效参数是

完整

提供针对 L1TF 漏洞的所有可用缓解措施。禁用 SMT 并启用虚拟机监控程序中的所有缓解措施,即无条件 L1D 刷新

引导后仍然可以通过 sysfs 接口控制 SMT 和 L1D 刷新。当第一台虚拟机以潜在不安全的配置(即 SMT 启用或 L1D 刷新禁用)启动时,虚拟机监控程序将发出警告。

full,force

与“full”相同,但禁用 SMT 和 L1D 刷新运行时控制。暗示“nosmt=force”命令行选项。(即,SMT 的 sysfs 控制被禁用。)

刷新

保持 SMT 启用,并启用默认的虚拟机监控程序缓解措施,即条件 L1D 刷新

引导后仍然可以通过 sysfs 接口控制 SMT 和 L1D 刷新。当第一台虚拟机以潜在不安全的配置(即 SMT 启用或 L1D 刷新禁用)启动时,虚拟机监控程序将发出警告。

flush,nosmt

禁用 SMT 并启用默认的虚拟机监控程序缓解措施,即条件 L1D 刷新。

引导后仍然可以通过 sysfs 接口控制 SMT 和 L1D 刷新。当第一台虚拟机以潜在不安全的配置(即 SMT 启用或 L1D 刷新禁用)启动时,虚拟机监控程序将发出警告。

flush,nowarn

与“flush”相同,但当虚拟机以潜在不安全的配置启动时,虚拟机监控程序不会发出警告。

关闭

禁用虚拟机监控程序缓解措施,并且不发出任何警告。它还取消了虚拟机监控程序和裸机上的交换大小和可用 RAM 限制。

默认值为“flush”。有关 L1D 刷新的详细信息,请参见 1. VMENTER 上的 L1D 刷新

KVM 的缓解控制 - 模块参数

KVM 虚拟机监控程序缓解机制(在进入访客时刷新 L1D 缓存)可以通过模块参数控制。

选项/参数是“kvm-intel.vmentry_l1d_flush=”。它接受以下参数

始终

每次 VMENTER 时刷新 L1D 缓存。

cond

仅当 VMEXIT 和 VMENTER 之间的代码可能泄露对攻击者来说“有趣”的主机内存时,才在 VMENTER 上刷新 L1D。这仍然可能泄露主机内存,从而例如可以确定主机的地址空间布局。

从不

禁用缓解措施

该参数可以在内核命令行中提供,作为加载模块时的模块参数,并在运行时通过 sysfs 文件修改

/sys/module/kvm_intel/parameters/vmentry_l1d_flush

默认值为“cond”。如果在内核命令行中给出“l1tf=full,force”,则强制执行“always”,kvm-intel.vmentry_l1d_flush 模块参数将被忽略,并且对 sysfs 文件的写入将被拒绝。

缓解选择指南

1. 未使用虚拟化

系统受到内核的无条件保护,无需采取进一步行动。

2. 具有受信任访客的虚拟化

如果访客来自受信任的来源,并且访客操作系统内核被保证已实施 L1TF 缓解措施,则系统完全受到 L1TF 的保护,无需采取进一步行动。

为避免 VMENTER 上默认 L1D 刷新的开销,管理员可以通过内核命令行和 sysfs 控制文件禁用刷新。参见 内核命令行上的缓解控制KVM 缓解控制 - 模块参数

3. 具有不受信任访客的虚拟化

3.1. SMT 不支持或已禁用

如果处理器不支持 SMT,或在 BIOS 或内核中禁用了 SMT,则只需在 VMENTER 上强制执行 L1D 刷新。

条件 L1D 刷新是默认行为,可以进行调整。参见 内核命令行上的缓解控制KVM 缓解控制 - 模块参数

3.2. EPT 不支持或已禁用

如果处理器不支持 EPT 或在虚拟机监控程序中禁用了 EPT,则系统将受到完全保护。SMT 可以保持启用,并且无需在 VMENTER 上刷新 L1D。

EPT 可以在虚拟机监控程序中通过“kvm-intel.ept”参数禁用。

3.3. SMT 和 EPT 受支持并已激活

如果 SMT 和 EPT 受支持并处于活动状态,则可以采用不同程度的缓解措施

  • VMENTER 上的 L1D 刷新

    VMENTER 上的 L1D 刷新是最低保护要求,但它只有与其他缓解方法结合使用时才有效。

    条件 L1D 刷新是默认行为,可以进行调整。参见 内核命令行上的缓解控制KVM 缓解控制 - 模块参数

  • 访客限制

    将访客限制到不运行任何其他进程的单个或一组物理核心,可以显著减少攻击面,但中断、软中断和内核线程仍可能向潜在攻击者暴露有价值的数据。参见 2. 访客 VCPU 限制到专用物理核心

  • 中断隔离

    将访客 CPU 与中断隔离可以进一步减少攻击面,但仍允许恶意访客探索有限的主机物理内存。这至少可以用于获取有关主机地址空间布局的知识。那些与运行不受信任访客的 CPU 具有固定亲和性的中断,根据具体场景,仍可能触发软中断并调度内核线程,从而可能暴露有价值的信息。参见 3. 中断亲和性

上述三种缓解方法结合使用可以在一定程度上提供保护,但必须仔细分析剩余攻击面的风险。为了获得全面保护,可以使用以下方法

  • 禁用 SMT

    禁用 SMT 并强制执行 L1D 刷新可提供最大程度的保护。此缓解措施不依赖于上述任何缓解方法。

    SMT 控制和 L1D 刷新可以通过命令行参数“nosmt”、“l1tf”、“kvm-intel.vmentry_l1d_flush”以及在运行时通过匹配的 sysfs 控制文件进行调整。参见 4. SMT 控制内核命令行上的缓解控制KVM 缓解控制 - 模块参数

  • 禁用 EPT

    禁用 EPT 也提供了最大程度的保护。它不依赖于上述任何缓解方法。SMT 可以保持启用,并且不需要 L1D 刷新,但性能影响显著。

    EPT 可以在虚拟机监控程序中通过“kvm-intel.ept”参数禁用。

3.4. 嵌套虚拟机

使用嵌套虚拟化时,涉及三个操作系统:裸机虚拟机监控程序、嵌套虚拟机监控程序和嵌套虚拟机。从嵌套虚拟机监控程序到嵌套访客的 VMENTER 操作将始终由裸机虚拟机监控程序处理。如果 KVM 是裸机虚拟机监控程序,它将

  • 在每次从嵌套虚拟机监控程序切换到嵌套虚拟机时刷新 L1D 缓存,以确保嵌套虚拟机监控程序的秘密不会暴露给嵌套虚拟机;

  • 在每次从嵌套虚拟机切换到嵌套虚拟机监控程序时刷新 L1D 缓存;这是一个复杂的操作,刷新 L1D 缓存可以避免裸机虚拟机监控程序的秘密暴露给嵌套虚拟机;

  • 指示嵌套虚拟机监控程序不执行任何 L1D 缓存刷新。这是一种避免重复 L1D 刷新的优化。

默认缓解措施

内核对易受攻击处理器的默认缓解措施是

  • PTE 反转以防止恶意用户空间攻击。这是无条件完成的,无法控制。交换存储限制在约 16TB。

  • 当为访客启用 EPT 时,在 VMENTER 上进行 L1D 条件性刷新。

内核默认不强制禁用 SMT,这使得在运行启用了 EPT 的不受信任访客时,SMT 系统仍易受攻击。

这一选择的理由是

  • 强制禁用 SMT 可能会破坏现有设置,尤其是在无人值守更新的情况下。

  • 如果普通用户在其机器上运行不受信任的访客,那么 L1TF 只是不受信任访客中可能嵌入的其他恶意软件的附加项,例如垃圾邮件机器人或对本地网络的攻击。

    从技术上讲,没有办法阻止用户盲目地在其机器上运行不受信任的代码。

  • 从技术上讲,L1TF 极不可能通过 JavaScript 等最流行的攻击机制被利用,因为这些机制无法控制 PTE,根据目前的知识甚至是不可能的。如果这可能发生且没有其他缓解措施可行,那么默认设置可能会有所不同。

  • 云和托管设置的管理员必须仔细分析其场景的风险,并做出适当的缓解选择,这甚至可能因其部署的机器而异,并导致其整体设置发生其他更改。内核无法为这种场景提供合理的默认设置。