LWN：Linux SVSM 项目！

关注了就能看到更多这么棒的文章哦～

The Linux SVSM project

January 30, 2023
This article was contributed by Carlos Bilbao
DeepL assisted translation
https://lwn.net/Articles/921266/

如果说传统网络像是只有少数几扇门的个人住宅，只有少数人拥有钥匙，那么基于云的环境就像是公寓楼。它既提供了更高的密度和更大的灵活性，但也有更多人拥有钥匙，以及更多的可能的入口。越来越需要保护在这些环境中运行的虚拟机（VM）能够不受主机和其他虚拟机用户的影响。Linux 安全虚拟机服务模块（SVSM）是一个新生的、基于 Rust 的开源项目，旨在帮助保护 AMD 硬件上虚拟机的保密性和完整性。

资源共享，可以让多用户的云环境可以高效利用资源，但是也会使虚拟机的内存、cache 和寄存器都有可能会被其他未经授权的访问获取到。相应地，保密计算（confidential computing）的目的就是保护虚拟机的保密性和完整性，使其不受其他虚拟机以及 host 的所有者的影响。这对于必须满足客户严格的安全要求从而销售其服务的云供应商来说，是特别值得关注的一点。可用性（availability）通常不是安全目标（security goal）的一部分，因为不受信任的供应商（也是这些威胁模型中的一个潜在攻击者）通常可以直接对 host 本身进行物理上的直接访问。

在一个不受信任的云基础设施上执行敏感操作时，许多资源，包括主机 BIOS、hypervisor、设备驱动程序、虚拟机管理器（VMM, virtual machine manager）和其他虚拟机都不能完全被信任。在这样一个很有限的可信计算基础（TCB，trusted computing base）下，root of trust 通常位于跟 CPU 和其他硬件都分离开的一个专用硬件组件上。SVSM 在 guest hypervisor 和 AMD 处理器上的这些组件的固件之间充当了中介的角色。在操作系统的范围内，一个 "service module" 就是一个独立的实体，主要是代表内核来执行操作的。由于内核本身不需要再执行这种操作，这样就可以由硬件来限制它做这些工作的能里了，从而阻止攻击者可能的滥用。

具体来说，Linux SVSM 提供了与 AMD Secure Processor（ASP）交互的 service，ASP 是 AMD 安全加密虚拟化（SEV, Secure Encrypted Virtualization）技术的一个关键组成部分。第三代 AMD EPYC 处理器引入的 "Zen 3" 架构使用 ASP 来保护 secured guest 的内存和寄存器状态；Linux SVSM 提供的服务就利用了这些硬件能力。Linux SVSM 根据 SVSM 规范来提供安全服务，从而帮助尽量减小 guest 的受攻击面。在 linux-coco confidential-computing 邮件列表中宣布了它的发布，该社区一直在积极讨论与开发有关的话题。Linux SVSM 是在虚拟化保密计算方向上的一个努力成果。要理解它的话就需要对最新的 SEV 特性进行介绍。

SNP features used by Linux SVSM

AMD 的 Secure Nested Paging（SNP）功能是随着 "Zen 3" 微架构而引入的保密计算的扩展之一。Linux SVSM 广泛使用了两个 SNP 特性：反向映射表（RMP，Reverse Map Table）和虚拟机权限级别（VMPLs, Virtual Machine Privilege Levels）；它还使用了一个被称为虚拟机保存区（VMSA, Virtual Machine Saving Area）的特殊区域。虚拟机的状态，也就是运行中的 guest 的 CPU 寄存器的完整快照，在虚拟机每次退出到 hypervisor 时都会被保存在 VMSA 中。

SNP 使用一个加载到 DRAM 的、每个 host 独立 RMP，来提供内存完整性保护。RMP 了包含系统中每个物理 page 的记录，并跟踪每个 page 的所有权和权限，以便（例如）在第三方试图写入它不应该写入的地方时触发 page fault。因此，RMP 会是 page table 遍历流程中的一个额外步骤。RMP 的使用场景包括防止数据损坏、数据别名以及 page 映射攻击等。RMP 中包含了每个物理页和其对应的 guest page 的映射；因此，每个物理页只能映射到一个 guest page。此外，攻击者可能试图在 guest 无法意识到的情况下改变映射到 guest page 的物理页；RMP 就可以挫败这种攻击。

在使用一个 page 之前，guest 必须首先验证它的 RMP 映射（RMP 的 entry 里包括了一个 valid bit，硬件会在 nested page walk 的最后一步检查这个 bit）。这通常是在初次启动时完成的，是内核用 PVALIDATE 指令准备 page table 的动作中的一部分。hypervisor 负责与 SVSM 合作管理 RMP，并且已经实现了硬件检查以确保 hypervisor 不会滥用 RMP。

SNP 还引入了虚拟机权限级别（VMPLs）的概念，取值范围是从 0 到 3，用来增强虚拟机内的硬件安全控制；VMPL0 是最高的权限级别，VMPL3 是最低的，类似于 X86 protection ring。VMPL 增加了访问控制的粒度，当某些虚拟 CPU（vCPU）试图访问它不应该访问的资源时，就可以导致虚拟机退出。每一个新的 page 被分配给一个 guest 并由其验证，在 VMPL0 这里就可以获得所有权限。guest 以后可以使用 RMPADJUST 指令来修改从而获得更高的权限级别。例如，运行在 VMPL1 的 guest 可以从运行在 VMPL2 或更高的 vCPU 来移除该 page 的执行权限。同样，这种类型的操作通常发生在启动期间。每个 guest 的 VMSA 包含它的 VMPL 级别，除非 SVSM 直接修改 VMSA，否则在启动后不能修改。

Linux SVSM 利用了这些（以及其他一些）新的 SNP 特性。它运行在 VMPL0，而 guest 操作系统运行在 VMPL1，这意味着 SVSM 将代表操作系统来执行所有需要 VMPL0 的 guest 操作。SVSM 还可以以安全的方式来提供其他服务（例如，可能进行实时迁移）。guest 的所有请求都使用 SVSM 规范中定义的 API，并且必须遵循每种 service 类型的协议规范。依靠 Linux SVSM 来处理某些操作，就极大地增强了 TCB 的可靠性，因为敏感的工作都从拥有许多攻击面的大型程序（如 Linux 内核）中改到规模较小的 SVSM 中。此外，由于 cloud virtualization 的扩张，作为目标的多个子系统（如内核随机化）现在不再需要进行各种级别的 audit 了，因为它们不再拥有特权了。

The Linux SVSM execution flow

Linux SVSM 不是一个操作系统，相反，它是一个由 hypervisor 加载的独立的二进制文件。从安全和内存的角度，以及从安全同步（safe synchronization）的角度，SVSM 都可以从 Rust 语言的强大静态保证中受益。Linux 的 SVSM 逻辑包括了内部的配置以及 VM guest 请求的处理。分析 Linux SVSM 的执行流程就可以更好地理解它。这个流程由以下四个阶段组成：

运行到 Rust SVSM 是虚拟机启动后由 hypervisor 执行的第一个 guest 代码。启动过程从引导处理器（BSP）内的 VMPL0 开始。在快速跳转到更高层次的独立 Rust 代码之前，少量的汇编代码会执行基本的初始化。不过，即使是用 Rust，有一些操作也需要在不安全的部分执行（例如，写 MSR 或解析指针）。Linux SVSM 依靠 x86_64 Rust crate 来处理大部分的 page。

内核组件的初始化 在 BSP 上运行的 SVSM 会进行一些检查，从而验证所提供的内存地址是否正确，以及是否确实是在 VMPL0 运行并使用了合适的 SEV。SVSM 还自己带有串行输出支持，以及自己的动态内存分配器（一个用于分配最大 2KB 的 slab 分配器和一个用于分配超过 2KB 的 buddy 分配方案）。所有这些组件都被初始化了，而且还发生了其他的操作系统的一些准备工作。

启动 APs 和 OVMF 在 SMP 下运行客户机时，BSP 会初始化其余的辅助处理器（APs, auxiliary processors），为它们每一个都准备一个 VMSA。启动后，各个 AP 跳到 SVSM request loop 的循环里。BSP 会找到开放虚拟机固件（OVMF，Open Virtual Machine Firmware）BIOS，准备 VMSA 从而让他可以在 VMPL1 运行，然后请求 hypervisor 来使用新的 VMSA 运行 OVMF 代码。OVMF 最终开始执行 guest 的 Linux 内核，该内核也是用 VMPL1 运行的。SVSM 也包含在 guest 的地址空间中，但是 guest 无法访问。每当 guest 操作系统需要执行特权级别的 VMPL 操作（比如验证 page）时，它会按照预定义的协议之一来跟 SVSM 进行通信。这时，当 guest 内核运行时，SVSM 就不再相关了，至少在该内核发出 service request 之前是如此。初始化过程就完成了。

请求循环（Request loop） 在一切都启动并运行起来之后，在 SVSM 内处理请求的进程就开始运行了。当 guest 需要在 VMPL0 执行某些操作（比如更新 RMP 来做 page validation）或者向 SVSM 请求其他服务（比如 virtual TPM 操作）时，它会遵循 SVSM 的 API，请求 hypervisor 运行与 SVSM 相关的 VMPL0 VMSA，从而触发一次上下文切换。这时，hypervisor 通过 SVSM 的 VMPL0 VMSA 发出 VMRUN 指令，恢复 SVSM。该请求被处理完成后，SVSM 会要求 hypervisor 来恢复 guest 的 VMPL1 VMSA。

这整个过程中，SVSM 是在 SEV 的 "Restricted Injection" 功能激活的情况下执行的。该功能禁用了虚拟中断队列（virtual interrupt queuing），并将 event-injection 的接口限制在只有 #HV（"hypervisor injection"）exception 上。SVSM 在运行时禁用了中断，并且不应该有任何 event 进来，否则会导致 SVSM 出现 double-faulting 并终止运行。执行这种操作模式是为了进一步降低 SVSM 内部的安全暴露（security exposure），并简化中断处理动作。

What's next?

Linux SVSM 需要 host 和 guest 的 KVM、QEMU 和 OVMF 子系统都必须更新版本。这些改动要么目前正在开发中，要么正在向 upstream 迈进。截至目前，SVSM 的代码仓库包括了初始化脚本，该脚本可以 clone 相关代码仓库并且进行必需的改动，从而方便开发者的工作。目前的重点是添加对 Linux 的支持。但是，SVSM specification 本身是跟操作系统无关的。

Linux SVSM 是一个正在积极开发的开源项目。因此是接受公众贡献的。目前正在开发对不同 x86 权限级别下运行的支持。一旦 SVSM 能够 offload 所有的安全操作，那么我们就能提供更多的 service，比如实时虚拟机迁移（live VM migration）。SVSM 的权限分离模型（privilege-separation model）也允许使用虚拟可信平台模块（virtual TPM, virtual Trusted Platform Module）。可以在 linux-coco 邮件列表中找到近期关于 vTPM 的可能设计方案的讨论。Linux SVSM 也可以从更细的安全粒度、文档、社区参与等方面受益。在这个过程中，有许多开源的开发领域和机会可以让大家参与进来，并能从系统整体的角度来学习 Rust。我们欢迎对项目的任何贡献。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～