AWS Firecracker VMM 微架构安全：微架构攻击与防御分析

链接表

• 摘要和引言
• 背景
• 威胁模型
• Firecracker 遏制系统分析
• Firecracker Microvms 中的微架构攻击与防御分析
• 结论、致谢和参考文献

5. Firecracker Microvm 中的微架构攻击与防御分析

在本节中，我们将介绍对 Firecracker microVM 上的许多微架构侧信道和推测攻击 PoC 的分析。我们在裸机和 Firecracker 实例上测试这些 PoC，并在各种场景中测试相关的微代码防御。我们在配备 Intel Skylake 4114 CPU 的服务器上运行测试

已启用虚拟化硬件扩展和 SMT。CPU 在微码版本 0x2006b06[2] 上运行。主机操作系统是 Ubuntu 20.04，带有 Linux 5.10 内核。我们使用 Firecracker v1.0.0 和 v1.4.0（截至 2023 年 7 月的最新版本）运行 Ubuntu 18.04 客户机，该客户机带有 Amazon 提供的 Linux 内核 5.4，并遵循快速入门指南[3]。

总之，AWS Firecracker 提供的推荐生产主机设置在保护租户免受恶意邻居攻击方面是不够的。因此，Firecracker 无法提供其声称的隔离保证。这是因为

(1) 我们识别出一种 Medusa 变体，该变体只有在微虚拟机上运行后才可被利用。此外，建议的对策不包含缓解侧信道或大多数其他 Medusa 变体的必要步骤。

(2) 我们表明，在应用建议的对策时，租户无法得到适当的保护，以免受到 Spectre-PHT 或 Spectre-BTB 引起的信息泄露。即使禁用 SMT，Spectre-PHT 变体仍然是一个问题。

（3）我们观察到 Firecracker v1.0.0 和 v1.4.0 之间的 PoC 性能没有差异。

我们得出结论，Firecracker 提供的虚拟化层对微架构攻击几乎没有效果，并且 Firecracker 的系统安全建议不足。

5.1 美杜莎

我们在测试系统的裸机和 Firecracker VM 上评估了 Moghimi 针对 Medusa [37] 侧信道（英特尔将其归类为 MDS [25] 的 MLPDS 变体）的 PoC [35]。第 2.4.2 节中描述的三种已知变体各有一个泄漏的 PoC。我们使用了 PoC 库中的两个受害者程序：

• “块写入”程序循环写入大量连续数据（以便处理器识别重复的存储并将它们组合起来）。

• “REP MOV”程序执行类似的操作，但使用 REP MOV 指令，而不是使用许多在循环中移动较小数据块的指令。

5.1.1 结果。表 1 显示了在禁用内核中的所有微架构保护的情况下成功泄露数据的情况。左边两列显示了三个 Medusa PoC 和两个包含的受害者程序的可能组合。右边的列表示哪些配置在裸机上有效，以及密钥和泄露程序在并行 Firecracker 实例中运行。最值得注意的是，对于 Cache Indexing 变体，Block Write 密钥仅适用于 Firecracker。这可能是因为虚拟机提供的内存地址虚拟化：客户机只能看到 KVM 映射的虚拟内存区域，而 KVM 会捕获内存访问指令并代表客户机处理事务。

我们在裸机和 Firecracker VM 上测试了 mds 和 nosmt 防御措施针对每种攻击者和受害者 PoC 组合的有效性。表 2 列出了在裸机和 Firecracker 场景中防止 Medusa 攻击所需的保护措施。在 Firecracker 的四个漏洞中，只有一个漏洞仅通过 nosmt 即可缓解，AWS 并未明确建议启用 mds 保护，尽管大多数 Linux 发行版都默认启用了该保护。也就是说，多租户云平台可以以符合 AWS 推荐的安全措施的方式使用 Firecracker，但仍然容易受到大多数 Medusa 变体的攻击，包括 Firecracker VMM 本身泄露用户数据的变体，而这些数据原本不会泄露。

5.2 RIDL 及更多

在本节中，我们将对 RIDL PoC 程序 [51] 进行评估，该程序与 van Schaik 等人的 2019 年论文 [50] 一起提供。RIDL 是一类 MDS 攻击，它利用来自 CPU 内部缓冲区（而不是来自缓存或内存）的推测性负载。RIDL PoC 存储库还包括在论文后续附录中发布的攻击示例以及 Fallout MDS 攻击的一种变体。

5.2.1 结果。表 3 显示了我们测试的 RIDL PoC 的一些基本信息以及相关对策在预防攻击方面的有效性。我们比较了对裸机和 Firecracker 的攻击，以评估亚马逊声称的 Firecracker microVM 系统硬件安全性的提高。对于 Firecracker 系统上的测试，我们区分了主机系统 (H) 和 Firecracker 客户机内核 (VM) 上启用的对策标志。除了 nosmt 和 mds 内核标志外，我们还测试了其他相关标志（参见第 2.4.4 节 [21]），包括 kaslr、pti 和 l1tf，但没有发现它们对任何这些程序有影响。我们排除了 tsx_async_abort 缓解措施，因为我们测试的 CPU 包含 mds 缓解措施，这使得 tsx_async_abort 内核标志变得多余 [20]。

总体而言，我们发现 mds 保护不足以抵御大多数 RIDL 攻击。但是，禁用 SMT 确实可以缓解大多数此类漏洞。这与英特尔 [25] 和 Linux 开发人员 [21] 的声明一致，即必须禁用 SMT 才能防止跨超线程的 MDS 攻击。这些 PoC 中的两个异常值是 alignment_write（需要主机上的 nosmt 和 mds）和 pgtable_leak_notsx（仅通过 mds 对策可以缓解）。依赖于 alignment_write 的泄漏使用对齐错误而不是页表错误泄漏来触发推测 [50]。RIDL 论文 [50] 和英特尔对相关 VRS 漏洞的文档 [26] 尚不清楚这种攻击与其他 PoC 中发现的基于页面错误的 MFBDS 攻击究竟有何区别，但我们的实验结果表明泄漏的微架构机制是不同的。 pgtable_leak_notsx 的行为有一个简单而合理的解释，它在这些 PoC 中是独一无二的，关键原因是：它是唯一一个在单个线程内跨越安全边界（从内核泄漏页表值）而不是从另一个线程泄漏的漏洞。不言而喻，禁用多线程对这个单线程漏洞的影响不大。然而，mds 对策在从内核特权执行切换到同一线程内的用户特权执行之前刷新微架构缓冲区，在攻击用户代码泄漏之前从 LFB 中擦除内核代码访问的页表数据。

与 Medusa 不同，AWS 建议禁用 smt，从而缓解了大多数 PoC 的威胁。但是，与 Medusa 一样，Firecracker VMM 本身不提供针对这些攻击的微架构保护。

5.3 幽灵

接下来我们重点关注 Spectre 漏洞。虽然自 Spectre 攻击首次被发现以来，已经开发出许多应对措施，但其中许多措施要么会带来（显著的）性能损失，要么只能部分缓解攻击。因此，

系统操作员通常必须在性能与安全性之间做出权衡。在本节中，我们将评估前面描述的两种威胁模型中 Firecracker 租户可用的 Spectre 攻击面。为了评估 Spectre 攻击的广泛范围，我们依赖于 [15] 中提供的 PoC。对于 Spectre-PHT、Spectre-BTB 和 SpectreRSB，存储库分别包含四个 PoC。它们的区别在于攻击者错误训练 BPU 的方式。这四种可能性是 (1) 同一进程 - 攻击者可以控制受害进程或其输入，从而错误训练 BPU - (2) 跨进程 - 攻击者在单独的进程中运行自己的代码，以影响受害进程的分支预测 - (a) 就地 - 攻击者使用位于与攻击者希望在受害进程中错误预测的目标分支相同的虚拟地址的分支指令错误训练 BPU - (b) 异地 - 攻击者使用位于与受害进程中的目标分支一致的地址的分支指令错误训练 BPU。

（1）相同进程：攻击者可以控制受害进程或其输入，从而对 BPU 进行错误训练，

（2）跨进程：攻击者在单独的进程中运行自己的代码，以影响受害进程的分支预测，

（3）就地：攻击者利用分支指令错误训练 BPU，该指令位于与攻击者希望在受害进程中错误预测的目标分支相同的虚拟地址

（4）不当位置：攻击者使用位于与受害进程中的目标分支一致的地址的分支指令错误地训练 BPU。

前两种情况和后两种情况是正交的，因此每个 PoC 都结合了其中两种情况。对于 Spectre-STL，只知道相同进程的变体，这就是为什么存储库在这种情况下只提供两个 PoC。对于跨虚拟机实验，禁用主机和客户机内核以及主机和客户机用户级别的地址空间布局随机化，以方便找到用于错误训练的一致地址。

5.3.1 结果。在主机系统和 Firecracker VM 中启用 AWS 推荐的对策[8]（所用 Linux 内核的默认措施，参见图 5）后，我们发现 Spectre-RSB 在主机上以及 VM 内部和跨 VM 均得到成功缓解（参见表 4）。另一方面，Spectre-STL、Spectre-BTB 和 Spectre-PHT 在特定情况下允许信息泄露。

Spectre-STL 的 PoC 显示了泄漏。但是，泄漏仅发生在同一进程和同一特权级别内。由于没有已知的跨进程变体，我们没有测试 Spectre-STL 的跨虚拟机场景。在我们的用户到用户威胁模型中，Spectre-STL 不是可能的攻击媒介，因为没有已知的跨进程变体。如果两个租户工作负载通过同一虚拟机内的进程内隔离进行隔离，Spectre-STL 仍可能是一个可行的攻击媒介。在用户到主机模型中，Spectre-STL 可以通过当前 Linux 内核中包含并默认启用的对策来缓解。

对于 Spectre-PHT，内核对策包括清理用户指针和在特权级别切换时使用屏障 (lfence)。因此，我们得出结论，SpectrePHT 对主机系统几乎没有威胁。然而，这些

如果两个超线程在同一个物理核心上并行执行，则缓解措施无法保护它们免受彼此影响。这就是为什么所有四种 Spectre-PHT 错误训练变体在主机系统和 Firecracker VM 内都能完全发挥作用的原因。如表 4 所示，即使禁用 SMT[4]，情况仍然如此。事实上，将两个 VM 固定到同一个物理线程会启用 Spectre-PHT 的跨进程异地版本，而我们在 SMT 情况下没有观察到泄漏。这使得 Spectre-PHT 对用户对用户构成了重大威胁。

当启用 AWS 推荐的对策时，Spectre-BTB PoC 可以部分发挥作用。在同一进程和同一地址错误训练 BTB 的原始变体可以完全发挥作用，而同一进程异地错误训练

成功缓解。此外，所有通过非就地错误训练跨进程边界泄漏信息的尝试均未显示任何泄漏。然而，通过跨进程就地错误训练，我们观察到了泄漏。在主机系统上，泄漏独立于 SMT 发生。在 VM 内部，只有当所有虚拟 CPU 核心都分配给单独的物理线程时才会发生泄漏。在 VM 之间，禁用 SMT 可消除泄漏。

除了图 5 中列出的对策之外，主机内核还在虚拟机入口和出口点[5]中编译了 Spectre 对策，以便在内核处理虚拟机退出时完全禁止恶意客户机攻击主机内核。

总而言之，我们可以说 AWS Firecracker 推荐的 Linux 默认对策只能部分缓解 Spectre。具体来说，我们显示：

• 在采取 AWS 建议的对策（包括禁用 SMT）的情况下，Spectre-PHT 和 Spectre-BTB 仍然会在客户到客户场景中在租户之间泄露信息。

• 主机内核可能受到编译到 Linux 内核中的额外预防措施的充分保护，以屏蔽虚拟机的进入和退出。然而，这与 Firecracker 提供的安全措施是相互矛盾的。

所有观察到的泄漏都与正在使用的 Firecracker 版本无关。

5.3.2 评估。我们发现 Firecracker 并未增加针对 Spectre 的缓解措施，而仅仅依赖于一般保护建议，其中包括主机和客户机内核提供的缓解措施以及可选的微代码更新。更糟糕的是，建议的对策不足以保护无服务器应用程序免于将信息泄露给其他租户。因此，我们声称 Firecracker 在微架构层面上没有实现其隔离目标，尽管微架构攻击被视为在 Firecracker 威胁模型的范围内。

细心的读者可能会想知道为什么 Spectre-BTB 在实施 STIBP 对策后仍然存在问题（参见图 5），因为此微代码补丁旨在阻止分支预测使用来自另一个线程的预测信息。这也让我们困惑了一段时间，直到最近 Google 发布了一份安全公告[6]，其中指出 Linux 6.2 中的一个缺陷，当启用 IBRS 时，该缺陷会一直禁用 STIBP 缓解措施。我们验证了被确定为导致该问题的代码部分也存在于 Linux 5.10 源代码中。因此，我们假设 Google 发现的相同问题也发生在我们的系统上。

[2] 将微码更新到较新的版本将会禁用系统上的 TSX，这将使得基于 TSX 的 MDS 变体的测试变得不可能。

[3] https://github.com/firecracker-microvm/firecracker/blob/dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] 这是通过将攻击者和受害者进程固定到同一个核心来模拟的 ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx