统一安全域：KVM Planes 如何驾驭硬件特权级

在现代云基础设施中，虚拟化在隔离工作负载方面发挥着基础性作用。传统的虚拟机监控程序（Hypervisor）将客户机操作系统放置在一个独立的安全域中，其权限低于宿主机软件。然而，随着对机密计算（Confidential Computing）需求的增长，虚拟化架构正进一步演进：即在单个虚拟机（VM）内部建立多个嵌套的安全域。

为了实现这一目标，CPU 和平台厂商开发了专门的硬件机制来创建微型安全域（Micro-enclaves）或分区环境。但面临的挑战在于：每种架构的实现方式均不相同。由 Jörg Rödel、Paolo Bonzini 以及 KVM 社区推进开发的 KVM planes，旨在提供一个统一的抽象层，使 Linux 系统能够无缝管理这些差异化的厂商特性，避免客户机或宿主机软件栈走向碎片化。

虚拟机内部安全域的需求驱动

当一个标准的操作系统内核在虚拟机内部启动时，它通常拥有对分配给该虚拟机的所有虚拟化硬件资源的完全访问权限。而机密计算打破了这种单体信任模型。

以在虚拟机内部实现一个软件可信平台模块（sTPM）为例：

• 安全漏洞： 如果主客户机内核保留对虚拟机整个地址空间的完全控制权，它就能读取或篡改 sTPM 的密钥，从而使安全保证失效。

• 解决方案： 将 sTPM 隔离在同一虚拟机内一个更小、权限更高的内核中。

• 安全保障： 如果 sTPM 在一个主客户机内核无法触及的独立（通常经过加密的）内存区域内运行，且其 CPU 执行状态无法被虚拟机的其余部分修改，那么即便客户机层面的其他部分遭到入侵，它依然能够保持安全。

硬件多样性：碎片化的挑战

各处理器厂商推出了不同的机制，将虚拟机划分为多个独立的权限区域。虽然它们的架构实现存在差异，但目标完全一致：

对于系统开发者而言，自然希望编写出的代码能够直接利用这些安全域，而无需针对每个 CPU 厂商维护多套依赖特定架构的代码逻辑。

引入 KVM Planes

KVM planes 正是针对 Linux 系统提出的统一抽象层提案。该项目源于 Paolo Bonzini 提交的早期探索性实现，近期由 Jörg Rödel 发布了最新的补丁集。

关于这个略带戏谑意味的命名由来，文档补丁中特别提到：

“另外，因为 x86 对此有三种称呼，而 Arm 只有一种，所以选择 Arm 的名称用于所有架构，以避免无休止的争论，顺便把所有人——可能也包括 KVM/arm64 开发者——都得罪一遍。”

                       +---------------------------------------+
                       |               虚拟机 (VM)             |
                       |                                       |
                       |  +---------------------------------+  |
                       |  |            Plane 0              |  |
                       |  |   (最高权限 / VTL1 /             |  |
                       |  |    SEV-SNP VMPL0 / 安全域)      |  |
                       |  +---------------------------------+  |
                       |                  |                    |
                       |       受控切换   | 通过 Hypervisor    |
                       |                  | 发起调用           |
                       |                  v                    |
                       |  +---------------------------------+  |
                       |  |            Plane 1+             |  |
                       |  |   (较低权限 / VTL0 /             |  |
                       |  |   SEV-SNP VMPL2 / 客户机 OS)    |  |
                       |  +---------------------------------+  |
                       |                                       |
                       +---------------------------------------+

核心架构与运行机制

• 权限表示： 单个 plane 封装了由硬件或 Hypervisor 实现的特定权限等级——无论它是 AMD VMPL、Intel TDX 分区、Hyper-V VTL，还是 Arm Realm Plane。

• 共享与隔离状态： 虚拟机内的所有 planes 共享相同的基址空间和许多硬件资源，但每个 plane 都维护着一套独立的 CPU 寄存器和特定的控制状态。

• Plane 切换： 当低权限 plane 需要向高权限 plane 请求服务时，执行流会降级（Trap）回 Hypervisor，由 Hypervisor 来完成 plane 上下文的切换。

• 标识符： Planes 由整数 ID 标识。该抽象层并没有在 ID 数字大小与相对权限高低之间强加固定的对应关系。

生命周期、权限动态与执行控制

Plane 的创建与 vCPU 分配规则

在虚拟机创建时，KVM 会初始化一个运行在最高权限模式下的初始 plane。随后，宿主机用户空间可以通过专门的 KVM API 来实例化额外的 planes：

• 创建 Plane： 调用全新的 KVM_CREATE_PLANE ioctl()，该调用会返回一个专门用于控制和配置该新 plane 的文件描述符。

• vCPU 分配： 虚拟 CPU（vCPU）直接归属于各个 plane。要执行计算任务，plane 必须至少分配一个 vCPU。任何较低权限 plane 所分配的 vCPU 集合，必须是为其更高权限 planes 所配置 vCPU 的子集。

权限控制原则

处于较高权限等级的 plane 可以为较低权限的 planes 设定访问控制和执行边界。然而，这里存在一条严格的限制：plane 不能赋予任何自身并不拥有的权限（例如对特定内存区域的访问权）。 此外，诸如控制中断注入与处理等关键系统管理任务，可以被严格限制仅由最顶层的 plane 执行。

调度策略的抉择

对于任意给定的虚拟 CPU，在同一时刻只能有一个 plane 处于执行状态。在最新的补丁集实现中，如果存在多个可运行的 plane，KVM 默认会优先运行 ID 编号最小 的那个。

这种调度策略在社区中引发了讨论：

1. 中立性歧义： KVM 文档明确指出，KVM 目前对较小 ID 代表更高还是更低权限保持中立。

2. 直觉预期： 开发者通常直觉上会预期最高权限的 plane 应该优先于未授权的工作负载获得执行权。

3. 用户空间控制： Paolo Bonzini 对这一决策做出了提问，并建议未来将调度决策权转交给用户空间。

实际应用与早期实现

最近发布的 RFC 补丁集展示了 planes 如何在真实架构中落地运行：

1. AMD SEV-SNP 与 Coconut SVSM

该补丁集实现了对 AMD SEV-SNP 权限等级的支持，并与 Coconut 安全 VM 服务模块（SVSM） 配合工作。Hypervisor 将 Coconut 部署在 VMPL0（最高权限等级），同时将主 Linux 客户机内核运行在 VMPL2。

2. Hyper-V 虚拟信任等级 (VTL) 与 HEKI

Sriram Nambakam 提交的另一个独立补丁集将 planes 与 Hyper-V VTL 结合——将安全内核运行在 VTL1，而标准客户机内核运行在 VTL0。

这一集成展现了多项关键的安全能力：

• 安全内核生命周期： 在系统启动阶段加载并引导启动安全内核。

• 跨 VTL 通信： 实现 VTL0 与 VTL1 之间可靠的开销控制与消息通信。

• Hypervisor 强制内核完整性（HEKI）： 利用 VTL1 确保 VTL0 的完整性（借鉴了 Mickaël Salaün 早期的设计思路）。

• 独立内存保护： VTL1 可独立保护客户机内存，封存内核可执行代码段与只读数据，参与内核模块加载校验，并对 kexec 镜像进行合法性验证。

现状与未来展望

尽管早期版本的补丁因文档缺乏和缺少变更日志（changelog）受到了一些评审反馈，但新提交的系列补丁已经通过拆分宿主机端和客户机端的支持，改善了代码的可读性与文档质量。

KVM planes 目前仍处于积极的演进阶段，社区正在通过会议研讨与邮件列表持续完善其设计。在高度碎片化的硬件架构之上构建通用的抽象层绝非易事，其 API 细节仍会不断调整。但毫无疑问，KVM planes 为 Linux 系统在虚拟机内部实现标准化机密计算迈出了关键的一步。