AWS Firecracker VMM 的微架构安全性：摘要和简介

链接表

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

抽象的

Firecracker 是 Amazon Web Services (AWS) 专为无服务器云平台构建的虚拟机管理器 (VMM)，这些服务基于每个任务为最终用户运行代码，自动管理服务器基础设施。Firecracker 提供快速轻量级的虚拟机，并承诺兼具容器的速度（通常用于隔离小任务）和虚拟机的安全性（后者往往以牺牲性能为代价提供更大的隔离）。AWS 声称，这种安全性和效率的结合不仅可以在同一硬件上运行来自不同用户的数千个用户任务，而且可以安全地运行，主机系统可以在活动任务之间快速频繁地切换。尽管 AWS 表示微架构攻击包含在其威胁模型中，但这类攻击直接依赖于共享硬件，就像无服务器计算的可扩展性依赖于前所未有的大量用户之间的共享硬件一样。

在这项工作中，我们调查了 Firecracker 抵御微架构攻击的安全性。首先，我们回顾了 Firecracker 所述的隔离模型和推荐的部署最佳实践，确定了无服务器平台的潜在威胁模型，并分析了潜在的弱点。然后，我们使用微架构攻击概念验证来测试 Firecracker 提供的隔离，发现它对 Spectre 或 MDS 攻击几乎没有保护作用。我们发现了两个特别令人担忧的案例：1) Medusa 变体威胁 Firecracker VM，但不威胁在其外部运行的进程，并且无法通过 AWS 推荐的防御措施进行缓解；2) Spectre-PHT 变体即使采取了推荐的对策并在系统中禁用了 SMT，仍然可以利用。总之，我们表明 AWS 夸大了 Firecracker VMM 固有的安全性，并为正确保护使用 Firecracker 的云系统提供了不完整的指导。

CCS 概念

• 安全和隐私→虚拟化和安全；侧信道分析和对策。

关键词

系统安全、微架构安全、虚拟机、虚拟机管理程序、无服务器、云系统

1. 引言

无服务器计算是云计算的一个新兴趋势，云服务提供商 (CSP) 为其客户提供运行时环境。这样，客户可以专注于维护其功能代码，而将与硬件、操作系统 (OS) 以及有时运行时相关的管理工作留给 CSP。常见的无服务器平台模型包括功能即服务 (FaaS) 和容器即服务 (CaaS)。由于单个功能通常很小，但客户的应用程序可以运行从一个到数千个功能，因此 CSP 的目标是在单个服务器上安装尽可能多的功能，以最大限度地减少空闲时间，从而最大限度地提高利润。一种相当轻量级的提供运行时环境的方法是运行容器，容器将进程与其依赖项封装在一起，以便只有每个进程所需的文件才会加载到共享内核顶部的虚拟文件系统中。这将容器之间的切换减少到只不过是进程之间的上下文切换。另一方面，完全虚拟化在虚拟机 (VM) 之间提供了良好的隔离，因此在租户之间提供了安全性，同时由于每个 VM 都有自己的内核，因此相当繁重。

容器或虚拟机这两种方法都不适合在无服务器环境中使用，在无服务器环境中，许多用户拥有的许多短期功能理想情况下会同时运行并经常切换，因此已经为这种用例开发了新的隔离机制。例如，进程内隔离机制 [38、45、49] 旨在通过减少运行时和底层内核的攻击面来提高容器的安全性。保护内核很重要，因为在容器情况下，内核受损会直接导致系统完全受损。然而，某些强大的保护措施（如限制系统调用）也会限制容器可用的功能，甚至破坏与某些应用程序的兼容性。在虚拟机研究中，开发人员创建了更小、更高效的虚拟机，最终产生了所谓的微虚拟机。微虚拟机提供与通常的虚拟机相同的隔离保证，但在设备或操作系统支持方面，其功能非常有限，这使得它们与通常的虚拟机相比更轻量级，因此更适合无服务器计算。

Firecracker [1] 是一种虚拟机管理器 (VMM)，旨在运行 microVM，同时提供与常见容器系统相当的内存开销和启动时间。Firecracker 由 Amazon Web Services (AWS) 积极开发，自 2018 年起已用于 AWS Lambda [5] 和 AWS Fargate [4] 无服务器计算服务的生产 [1]。AWS 的设计论文 [1] 描述了 Firecracker 的功能、它与更传统的虚拟机的区别以及它提供的预期隔离模型：确保“在同一硬件上运行的多个功能的安全性，防止特权升级、信息泄露、隐蔽通道和其他风险” [1]。此外，AWS 还提供了生产主机设置建议 [8]，以保护 Firecracker VM 与之交互的 CPU 和内核部分的安全。在本文中，我们对 Firecracker 保护功能免受跨 microVM 的隐蔽和侧通道攻击的说法提出了质疑。我们表明，Firecracker 本身不会增加微架构攻击对策，而是完全依赖于主机和客户机 Linux 内核以及 CPU 固件/微码更新。

各种 Spectre [10、13、22、30、31、33、52] 和微架构数据采样 (MDS) [14、37、46、50] 变体等微架构攻击对多租户系统构成威胁，因为它们通常能够绕过软件和架构隔离边界，包括虚拟机的隔离边界。Spectre 和 MDS 威胁共享 CPU 核心资源（如分支预测单元 (BPU) 或行填充缓冲区 (LFB)）的租户。提供更传统服务的 CSP 可以通过将长期存在的虚拟机租户固定到单独的 CPU 核心来缓解共享硬件资源的问题，这有效地在租户之间划分资源并确保微架构状态一次只受单个租户的影响。

然而，在无服务器环境中，微架构攻击的威胁更大。其原因是不同租户运行的功能寿命较短。无服务器环境中的服务器资源预计会被过度使用，这会导致租户功能在同一硬件上争夺计算资源。禁用同步多线程 (SMT) 会禁用两个同级线程对 CPU 资源的并发使用，从而将 CPU 的计算能力降低多达 30% [34]。如果客户租用特定的 CPU 内核，这种性能损失可能是可以接受的，或者 CPU 内核上的两个线程可能会一起租用。但对于无服务器服务，性能损失直接意味着在给定时间内可服务的客户数量减少了 30%。这就是为什么必须假设大多数无服务器 CSP 在其系统中启用 SMT，除非他们另有说明。如果启用了 SMT 并且恶意线程可以并发访问共享内核，则微架构攻击面最大。但是，如果攻击者线程在将 CPU 核心交给受害者线程之前准备好微架构，或者在受害者线程暂停执行后立即执行，则攻击变体的效果也一样好。即使 CSP 禁用了 SMT（就像 AWS Lambda 的情况一样），租户仍然会以这种时间分片的方式与多个其他租户共享 CPU。

AWS 声称，在具有最新微架构防御功能的系统上运行的 Firecracker 将提供足够的强化来抵御微架构攻击 [1]。Firecracker 文档还包含应启用的微架构安全措施的具体建议。在本文中，我们研究了 Firecracker 的安全声明和建议，并揭示了其指导中的疏忽以及完全无法缓解的威胁。

总而言之，我们的主要贡献是：

• 我们对基于 Firecracker VM 的无服务器计算的跨租户和租户虚拟机管理程序隔离提供了全面的安全分析。

• 我们测试了 Firecracker 针对微架构攻击概念验证 (PoC) 的防御能力，采用了通过微代码更新和 Linux 内核提供的保护。我们发现虚拟机本身对主要类型的微架构攻击的保护微不足道。

• 我们识别出 Medusa MDS 攻击的一个变体，即使主机上不存在该变体，它也可以从 Firecracker VM 内部利用。AWS 的 Firecracker 主机设置建议中未提及可防范此漏洞以及大多数已知 Medusa 变体的内核缓解措施。此外，我们表明禁用 SMT 无法充分保护已识别的 Medusa 变体，这迫切需要内核缓解措施。

• 我们识别出 Spectre-PHT 和 Spectre-BTB 变体，即使采取了推荐的对策，它们仍会泄露数据。如果攻击者和受害者以时间分片方式共享 CPU 核心，那么即使禁用 SMT，Spectre-PHT 变体仍会存在问题。

1.1 负责任的披露

我们将发现告知了 AWS 安全团队，并讨论了技术细节。AWS 安全团队声称，由于额外的安全措施，AWS 服务不受我们的发现的影响。AWS 同意 Firecracker 本身不提供微架构安全性，而仅与微代码更新和安全主机和客户操作系统结合使用，并计划更新其针对 Firecracker 安装的主机设置建议。