AWS Firecracker VMM 的微架构安全性：Firecracker 遏制系统分析

链接表

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

4. 爆竹遏制系统分析

图 2 显示了 AWS 提供的 Firecracker 遏制措施。在本节中，我们将分析每个描述的组件及其对微架构攻击的防御和漏洞

KVM 。基于 Linux 内核的虚拟机 (KVM) 是在现代 Linux 内核中实现的虚拟机管理程序，因此是 Linux 代码库的一部分。它虚拟化底层硬件的管理模式和用户模式，管理虚拟机之间的上下文切换，并处理大多数虚拟机退出原因（除非它们与 I/O 操作有关）。除了这些架构隔离机制之外，KVM 还实施了针对虚拟机退出时 Spectre 攻击的缓解措施，以保护主机操作系统或虚拟机管理程序免受恶意客户的攻击。Firecracker 严重依赖 KVM 作为其虚拟机管理程序。但是，由于 KVM 是 Linux 源代码的一部分并由 Linux 社区开发，我们将 KVM 定义为不是 Firecracker 的一部分。因此，在 KVM 中实施的针对微架构攻击的对策不能归因于 Firecracker 的遏制系统。

元数据、设备和 I/O 服务。元数据、设备和 I/O 服务是 Firecracker VMM 和 API 的一部分，它们直接与 VM 交互，收集和管理指标并提供连接。AWS 宣称这些接口非常简单（以减少攻击面），并且它们是用 Rust（一种以安全功能而闻名的编程语言）为 Firecracker 从头编写的 [9]。然而，Rust 最值得注意的是提供了针对无效和越界内存访问的进程内保护，但缓存攻击、Spectre 和 MDS 等微架构攻击可能会在进程之间泄露信息，而不是直接劫持受害者的进程。

Firecracker 与许多其他 VMM 之间的另一个显著区别是，所有这些服务都与 VM 本身在同一个主机进程中运行，尽管在另一个线程中。虽然 VM 中的内存地址虚拟化在客户机代码和 I/O 服务之间提供了一些混淆，但一些 Spectre 攻击专门在单个进程中工作。然而，进程内攻击对现实世界系统的威胁可能较小，因为在同一硬件上运行的两个客户机各自拥有这些基本服务的副本。

Jailer 屏障。如果 API 或 VMM 受到攻击，Jailer 将在 Firecracker 实例周围提供最后一道防御屏障。它分别使用命名空间和控制组 (cgroup) 保护主机系统的文件和资源 [7]。微架构攻击不会直接威胁文件，因为文件在定义上不在微架构状态之内。cgroup 允许系统管理员将进程分配给组，然后按组分配、限制和监控系统资源使用情况 [17]。对 cgroup 施加限制可能会阻碍攻击者实施某些微架构攻击的能力，这是合理的。例如，内存限制可能会使基于驱逐的缓存攻击变得困难，或者 CPU 时间限制可能会阻止攻击者有效使用 CPU 拒绝服务工具（如 HyperDegrade [2]），该工具可能会减慢受害进程的速度，从而简化微架构侧信道泄露或注入的时间。实际上，Firecracker 不附带任何特定的 cgroup 规则 [7]；事实上，它是专门为在默认 Linux 资源分配下许多 Firecracker VM 的高效运行而设计的 [6]。

Firecracker 中的任何隔离和遏制系统似乎都无法直接防御用户对用户或用户对主机的攻击。因此，我们继续在 Firecracker VM 内部和外部测试各种微架构攻击概念验证。