机密计算: AMD SEV-SNP 白皮书
简介
2016年，AMD 推出了第一个x86技术– 安全加密虚拟化(Secure Encrypted Virtualization，SEV) ，旨在将虚拟机与虚拟机管理程序隔离。虽然虚拟机管理程序在传统上是虚拟化安全模型中的可信组件，但许多市场可以从不同的VM信任模型中获益。例如，在云中，客户可能希望基于VM的工作负载免受云管理员的损害，以保持数据机密性，并尽量减少暴露在云提供商的基础设施中的缺陷。这就导致了在硬件级别上将 “虚拟机” 与 “虚拟机管理程序和可能在物理服务器上共存的其他代码” 隔离的需求。
AMD 开始通过在 SEV 中使用主存加密来应对这一挑战。通过该技术，可以为单个 VM 分配唯一的 AES 加密密钥，用于自动加密其正在使用的数据。当管理程序等组件试图读取访客内部的内存时，它只能看到加密的字节。
2017年，AMD推出了 SEV-ES(Encrypted State) 特性，为CPU寄存器状态增加了额外的保护。在 SEV-ES 中，每个虚拟机管理程序变迁上的虚拟机寄存器状态都被加密，这样虚拟机管理程序无法看到虚拟机正在主动使用的数据。与 SEV 一起，SEV-ES 可以通过帮助保护内存中数据的机密性来减少 VM 的攻击面。
本白皮书介绍了下一代SEV-SNP(Secure Nested Paging)。SEV-SNP 在现有 SEV 和 SEV-ES 功能的基础上，增加了新的基于硬件的安全防护。SEV-SNP 增加了强大的内存完整性保护，以帮助防止数据重放、内存重映射等基于虚拟机管理程序的恶意攻击，从而创建隔离的执行环境。此外，SEV-SNP 引入了一些额外的可选安全增强，旨在支持额外的 VM 使用模型，提供更强的中断行为保护，并提供更多的保护来抵御最近披露的侧信道攻击。
本文将 SEV、SEV-ES 和 SEV-SNP 统称为 AMD SEV 技术。
完整性
与 AMD SEV 技术结合使用的AES加密提供了更高的内存机密性保护。不知道加密密钥的攻击者无法破译存储在DRAM中的VM数据。SEV 内存加密密钥本身由硬件随机数发生器产生，存储在软件无法直接读取的专用硬件寄存器中。此外，硬件的设计使得相同的明文在不同的内存位置会有不同的加密方式。
尽管进行了加密，但即使不知道加密密钥，攻击者也可能试图改变内存中的值。这些类型的攻击被称为完整性攻击，因为内存中的值与VM的意图不一样。攻击者无法在不知道加密密钥的情况下轻易地将已知数据放入VM的内存中，但他们可能会破坏内存，使VM看到随机值或进行重放攻击。在重放攻击中，攻击者在某一时间点捕获密文，然后用先前捕获的数据替换内存。如果攻击者知道原始数据是什么，这种类型的攻击更加有效。
完整性攻击本身并不会直接危害 VM，VM 内部的软件必须利用不正确的数据导致信息泄露。这样的攻击是否成功取决于 VM 内部的软件以及它在遇到这种泄露的数据时的行为。由于 VM 中的软件通常不知道其内存完整性是否已受损，因此其在这种情况下的行为可能具有挑战性。
SEV-SNP 旨在防止基于软件的完整性攻击，并降低与内存完整性受损相关的风险。SEV-SNP完整性的基本原理是，如果一个VM能够读取一个私有(加密)的内存页，那么它必须始终读取上一次写入的值。（ The basic principle of SEV-SNP integrity is that if a VM is able to read a private (encrypted) page of memory, it must always read the value it last wrote. ）这意味着，如果VM向内存位置 X 写入一个值 A，那么每当它以后读取 X 时，它必须要么看到值 A，要么必须得到一个异常，表明该内存不能被读取。SEV-SNP 的设计是为了使 VM 不能看到与内存位置 X 不同的值。为了支持标准虚拟机任务，无论在读取和最后一次写入之间内存发生什么情况，此保证都必须成立。如果该内存页面被交换到磁盘，或者即使整个虚拟机被迁移到新主机，完整性保证仍然必须成立。实施此完整性保证需要结合使用本白皮书后面讨论的新 CPU 硬件和固件。
在典型的用例中，虚拟机既要执行自己的任务，又要通过 I/O 与外部实体进行通信。这可能包括通过网络链路、与存储服务器或其他组件进行通信。在 SEV 架构中，这种通信是使用共享(未加密)内存完成的。VM 希望提供的任何传出数据都被放置在内存的共享页中，任何传入数据也必须被放置在共享页中。由于共享内存不使用虚拟机的特定密钥进行加密，因此I/O流的安全性需要使用合适的软件加密协议，如HTTPS。
AMD SEV VM 使用客户机页表中的加密位 (C 位) 来控制内存页面是私有的还是共享的。C 位的位置由实现定义，可能是顶部物理地址位，如图所示。共享（未加密）内存由 VM 标记为 C=0，表示它不必使用 VM 的内存加密密钥进行加密。私有（加密）内存页面仅供该 VM 使用，标记为 C=1。在典型的 VM 中，大多数页面都标记为私有，只有外部通信所需的选定页面才标记为共享。与 SEV 机密性保证一样，SEV-SNP 完整性保证仅适用于私有客户机页面。
威胁模型
与之前的 SEV 和 SEV-ES 功能一样，在 SEV-SNP 下，AMD 片上系统 (SOC) 硬件、AMD 安全处理器 (AMD-SP) 和 VM 本身都被视为完全受信任。VM 负责保护自身及其接口，并且应遵循标准最佳实践来保护其使用的任何 I/O 数据，例如网络流量、硬盘数据等。为此，AMD 强烈建议在受保护的 VM 中使用全盘加密 (FDE) 解决方案，因为所有 SEV 技术都只保护正在使用的数据。FDE 保护静态数据，并且存在许多流行的商业解决方案。
在 SEV-SNP 下，所有其他 CPU 软件组件和 PCI 设备都被视为完全不受信任，如图所示。这包括主机系统上的 BIOS、虚拟机管理程序、设备驱动程序、其他 VM 等。完全不受信任意味着这些组件被视为恶意的，可能与其他不受信任的组件合谋破坏 SEV-SNP VM 的安全保障。
SEV-SNP 威胁模型包含旨在防御比以前的 AMD SEV 技术更多的威胁的功能。SEV 和 SEV-ES 使用“良性但易受攻击”虚拟机管理程序的威胁模型。在此威胁模型中，虚拟机管理程序不被认为是 100% 安全的，但可以信任它以良性意图行事。这意味着，虽然虚拟机管理程序并没有主动试图破坏其下的 SEV VM，但它本身可能存在可利用的漏洞。通过阻止或使某些攻击更加困难，SEV 和 SEV-ES 技术可以帮助限制某些类型的虚拟机管理程序错误的潜在暴露或显著提高利用的难度。SEV-SNP 解决了额外的攻击媒介和对 VM 安全的潜在威胁。表总结了各种 SEV 技术解决和未解决的威胁。
| 潜在威胁 (✅ = 已缓解，⭕ = 可选缓解措施，🚫 = 未缓解) | SEV | SEV-ES | SEV-SNP |
|---|---|---|---|
| 机密性 | |||
| 虚拟机内存攻击示例：虚拟机管理程序读取私有虚拟机内存 | ✅ | ✅ | ✅ |
| VM 寄存器状态示例攻击：在 VMEXIT 之后读取 VM 寄存器状态 | 🚫 | ✅ | ✅ |
| DMA 保护示例攻击：设备尝试读取虚拟机内存 | ✅ | ✅ | ✅ |
| 完整性 | |||
| 重放保护示例攻击：用旧副本替换虚拟机内存 | 🚫 | 🚫 | ✅ |
| 数据损坏示例攻击：用垃圾数据替换虚拟机内存 | 🚫 | 🚫 | ✅ |
| 内存别名攻击示例：将两个客户页面映射到同一个 DRAM 页面 | 🚫 | 🚫 | ✅ |
| 内存重新映射攻击示例：将 DRAM 页面切换到客户页面 | 🚫 | 🚫 | ✅ |
| 有效性 | |||
| 虚拟机管理程序上的拒绝服务攻击示例：恶意客户拒绝让步/退出 | ✅ | ✅ | ✅ |
| 拒绝客户机服务攻击示例：恶意虚拟机管理程序拒绝运行客户机 | 🚫 | 🚫 | 🚫 |
| 物理访问攻击 | |||
| 离线 DRAM 分析示例攻击：冷启动 | ✅ | ✅ | ✅ |
| 主动 DRAM 损坏示例攻击：在虚拟机运行时操纵 DDR 总线 | 🚫 | 🚫 | 🚫 |
| 杂项 | |||
| TCB 回滚示例攻击：将 AMD-SP 固件恢复为旧版本 | 🚫 | 🚫 | ✅ |
| 恶意中断/异常注入示例攻击：在 RFLAGS.IF=0 时注入中断 | 🚫 | 🚫 | ⭕ |
| 间接分支预测器中毒攻击示例：从虚拟机管理程序中毒 BTB | 🚫 | 🚫 | ⭕ |
| 安全硬件调试寄存器攻击示例：在调试期间更改断点 | 🚫 | 🚫 | ⭕ |
| 可信 CPUID 信息攻击示例：虚拟机管理程序谎报平台功能 | 🚫 | 🚫 | ⭕ |
| 架构侧信道攻击示例：PRIME+PROBE 跟踪虚拟机访问 | 🚫 | 🚫 | 🚫 |
| 页面级侧通道攻击示例：通过页表跟踪虚拟机访问模式 | 🚫 | 🚫 | 🚫 |
| 性能计数器跟踪示例攻击：通过性能数据对VM应用程序进行指纹识别 | 🚫 | 🚫 | 🚫 |
- 机密性：如前所述，机密性威胁通过当前所有 SEV 技术中都存在的基于硬件的内存加密来处理。这可以防止不受信任的组件（例如虚拟机管理程序或支持 DMA 的设备）直接读取 VM 中的明文（当然，除非 VM 选择允许不受信任的页面访问）。SEV-ES 技术为 VM 寄存器状态添加了机密性保护，当 VM 退出回虚拟机管理程序时加密此状态。SEV-SNP 中也存在此保护。
- 完整性：SEV-SNP 技术旨在防止完整性攻击，包括数据重放、损坏、重新映射和基于别名的攻击。保证虚拟机始终看到其上次写入的数据意味着必须防止所有这些攻击媒介。
- 可用性：任何虚拟化平台的可用性都有两个方面。第一是确保虚拟机管理程序保留对系统的控制，并且客户虚拟机无法拒绝虚拟机管理程序运行或以其他方式使物理机器无法使用。所有 SEV 技术都支持这种级别的可用性，并保证虚拟机管理程序始终可以在需要时重新获得控制权（例如，通过物理计时器中断）或在未经该虚拟机同意的情况下随时终止客户。可用性的第二个方面是客户是否享有任何可用性保证，例如最短运行时间。这不是任何 SEV 技术威胁模型的一部分，因为恶意虚拟机管理程序始终可以选择永远不运行客户虚拟机的部分或全部。
- 物理访问攻击：虽然某些物理攻击（例如 DRAM 冷启动攻击（离线分析 DRAM 芯片））可以通过这些技术阻止，但在线 DRAM 完整性攻击（例如在 VM 主动运行时攻击 DDR 总线）超出了范围。这些攻击非常复杂，需要大量本地访问和资源才能执行。
- 其他：还有其他几种针对安全 VM 的潜在攻击，其中一些属于此威胁模型的范围。例如，SEV-SNP 包含有助于防止可信计算库 (TCB) 回滚攻击的功能。如后所述，这启用了加密方法来验证系统中的 AMD-SP 固件和其他可信组件是否符合 VM 的策略。
此外，SEV-SNP 还可选地支持限制中断和异常注入 VM 的方式。它还可以支持针对某些类型的旁道攻击的分支目标缓冲区 (BTB) 保护。这两种保护措施将在本白皮书的后面部分讨论。
最后，有些类型的攻击不属于这三个功能中的任何一个的范围。
任何硬件手段都无法专门阻止对 CPU 数据结构的架构旁道攻击。与标准软件安全实践一样，对此类旁道攻击敏感的代码（例如加密库）应以有助于防止此类攻击的方式编写。当前一代技术也不支持指纹识别攻击保护。指纹识别攻击试图通过监视 VM 的访问模式、性能计数器信息等来确定 VM 正在运行的代码。虽然指纹识别有时可以提供有关 VM 内部运行的代码的信息，但通常最敏感的信息是数据本身（例如数据库中的数据），而不是正在运行的代码（例如正在使用哪个版本的数据库软件）。因此，当前的 SEV 技术主要侧重于保护敏感的 VM 数据内容。未来的 SEV 技术可能会提供针对某些指纹攻击的额外保护。
完整性威胁
| 威胁 | 期望的安全属性 | SEV-SNP 执行机制 |
|---|---|---|
| REPLAY PROTECTION | 只有内存页面的所有者才能写入该页面 | 反向映射表 (RMP) |
| DATA CORRUPTION | 只有内存页面的所有者才能写入该页面 | 反向映射表 (RMP) |
| MEMORY ALIASING | 每个物理内存页面一次只能映射到一个客户页面 | 反向映射表 (RMP) |
| MEMORY RE-MAPPING | 每个客户页面一次只能映射到一个物理内存页面 | 页表验证 |
上一节重点介绍了四种独特的完整性威胁：重放保护、数据损坏、内存别名和内存重新映射。防范这些威胁需要实施不同的安全属性，如表所示。在基于重放保护和数据损坏的攻击中，这些攻击依赖于不受信任的代码能够写入受保护 VM 的内存。 SEV-SNP 通过强制只有内存页面的所有者（例如，页面被分配到的 SEV-SNP VM）可以写入该页面来解决此问题。此强制执行是使用下一节中描述的反向映射表 (Reverse Map Table，RMP) 机制完成的。
内存别名攻击（Memory Aliasing attacks）涉及虚拟机管理程序恶意同时将两个不同的客户机页面映射到同一个物理内存页面。客户机自然希望其客户机物理地址空间中的不同页面映射到不同的内存，因此任何别名都可能导致意外的数据损坏。解决此威胁需要确保每个物理内存页面一次只能映射到一个客户机页面。同样，RMP 结构用于强制执行此属性。
最后一个完整性威胁是内存重映射（Memory Re-Mapping），涉及虚拟机管理程序恶意将单个客户机页面重新映射到多个不同的物理内存页面。在这种威胁下，客户机可能会看到不一致的内存视图，其中只有它写入的数据子集出现在内存中。解决这一威胁需要确保每个客户机页面一次只映射到一个物理内存页面，并且除了 AMD-SP 等受信任实体之外，这种映射不能被更改。SEV-SNP 使用一种称为页面验证的机制来解决这一威胁。页面验证依赖于新的 RMP 机制与新的 VM 代码的组合来管理客户机内存和系统内存之间的注入关系。
反向映射表
如上所述，SEV-SNP 的许多完整性保证都是通过一种称为反向映射表 (Reverse Map Table，RMP) 的新结构来执行的。RMP 是整个系统共享的单一数据结构，其中包含虚拟机可能使用的每 4k 页 DRAM 的一个条目。RMP 的目标很简单：它跟踪每个内存页的所有者。内存页面可以由虚拟机管理程序拥有，由特定虚拟机拥有，或由 AMD-SP 拥有。对内存的访问受到控制，因此只有该页面的所有者才能写入它。RMP 与标准 x86 页表结合使用，以强制执行内存限制和页面访问权限。
RMP 由系统物理地址索引，并在 CPU 和 IOMMU 表遍历结束时进行检查。例如，在本机（非 VM）模式下，使用标准 x86 页表将虚拟地址转换为物理地址。完成转换后，使用最终物理地址来索引 RMP。读出并检查 RMP 条目。如果 RMP 条目表明该页面是虚拟机管理程序拥有的页面，则检查通过并创建新的 TLB 条目。但是，如果 RMP 条目表明该页面不是虚拟机管理程序拥有的页面，则表遍历（table-walk）失败（#PF）并拒绝访问。
在 SEV-SNP VM 中运行时，RMP 检查稍微复杂一些。与本机模式一样，虚拟地址首先被转换为系统物理地址。
在这种情况下，AMD-V 2 级分页 1 用于将客户虚拟地址 (Guest Virtual Address，GVA) 转换为客户物理地址 (Guest Physical Address，GPA)，最后转换为系统物理地址 (System Physical Address，SPA)。SPA 用于索引 RMP 并检查条目。此 RMP 条目应包含指示该页面是客户拥有的页面、分配给此特定客户并映射到此特定 GPA 的信息。也就是说，RMP 条目包含应映射到的 GPA，并且硬件验证此 GPA 是否与当前表遍历（table-walk）的 GPA 匹配。如果此检查或任何其他检查失败，则会生成异常。
并非每次内存访问都需要 RMP 检查。特别是，来自虚拟机管理程序（或非 SEV-SNP 客户机）的读取访问不需要 RMP 检查，因为数据机密性已通过 AES 内存加密得到保护。否则，任何模式下的所有写入访问都需要 RMP 检查，并且对 SEV-SNP 内部私有内存页面的读取和写入访问都需要 RMP 检查。写入访问包括标准内存写入以及作为页表遍历一部分的 A/D 位更新。与标准 x86 分页一样，RMP 检查的结果缓存在 CPU TLB 和相关结构中。
由于 RMP 用于强制执行对内存的访问控制，因此表本身不能由软件直接写入。存在新的 CPU 指令来启用对 RMP 条目的操作，允许虚拟机管理程序将页面分配给特定客户机、收回页面等。在需要时，硬件会自动执行 TLB 无效化，以确保系统中的所有处理器都能看到更新的 RMP 条目信息。
页表验证
如前所述，每个 RMP 条目都包含应将特定 DRAM 页面映射到的 GPA。这通过构造确保每个 SPA 一次只能映射到一个 GPA。相反，单个 GPA 映射到多个 SPA 也不能满足 SEV-SNP 完整性保证。虽然嵌套页表确保每个 GPA 只能映射到一个 SPA，但虚拟机管理程序可能会随时更改这些表。SEV-SNP 完整性要求以这种方式操作表不能破坏所需的完整性，这通过验证的概念来解决。
每个 RMP 条目内都有一个 Validated bit，当为客户机创建新的 RMP 条目时，CPU 硬件会自动将此位清除为 0。分配给客户机但已清除 Validated bit 的页面不能由虚拟机管理程序使用或用作私人客户机页面，因为该页面未经验证访客只能在通过新的 CPU 指令 PVALIDATE 设置 Validated bit 后才能使用该页面。只有访客能够使用 PVALIDATE，并且每个客户机虚拟机只能验证自己的内存。
因此，向客户虚拟机添加新页面需要两个步骤，如上图所示。首先，虚拟机管理程序使用新的 RMPUPDATE 指令将页面分配给访客。这会将页面转换为 Guest-Invalid 状态。其次，客户机使用新的 PVALIDATE 指令验证页面，以将页面转换为 Guest-Valid 状态，然后可以使用该页面。
为了满足 SEV-SNP 所需的完整性，客户虚拟机不应多次验证与同一 GPA 对应的内存。这可以通过客户虚拟机在启动时验证其所有内存并拒绝验证其他内存（热插拔事件除外）来实现。或者，客户虚拟机可以跟踪已验证的内存位置并拒绝两次验证同一个内存位置。假设客户虚拟机正确验证了其内存，这可以保证 GPA 和 SPA 之间的注入映射。客户虚拟机将仅验证每个 GPA 一次，并且 RMP 表通过构造确保每个 SPA 只能映射到一个 GPA。
如果执行正确，页面验证可以阻止如下图所示的重新映射攻击。在此示例中，GPA A 最初映射到 SPA X。客户机执行 PVALIDATE 来验证此转换，这会导致 SPA X 对应的 RMP 条目中的 Validated 位被设置。如果虚拟机管理程序随后恶意尝试将 A 重新映射到不同的 SPA Y，它将首先为 SPA Y 创建 RMP 条目，并尝试使用 RMPUPDATE 指令映射相同的 GPA A。然后，虚拟机管理程序恶意修改嵌套页表 (NPT) 以将 GPA A 重新映射到 Y。但是，当客户机访问 Y 时，它将收到 #VC（VMM Communication）异常。发生此异常是因为 SPA Y 对应的 RMP 条目中的 Validated 位被清除（因为当执行 RMPUPDATE 为客户机分配新页面时，它最初清除了 Validated 位）。由于客户机知道它已经验证了 GPA A，因此
它知道它不应该收到验证错误，因此它受到了攻击，并且虚拟机管理程序无法正常运行。作为响应，客户机可以终止或采取其他措施来保护自己。
页表状态
如图所示，SEV-SNP 中的 RMP 跟踪每个内存页面的状态。这些状态决定了内存的用途、允许谁读取/写入内存以及页面稍后可以转换为哪些状态。例如，处于 Hypervisor 状态的页面可以由虚拟机管理程序读取/写入，也可以由使用 C=0（共享页面）访问内存的 SEV-SNP VM 读取/写入。相比之下，处于 Guest-Valid 状态的页面可以由 SEV-SNP VM 读取/写入，但不能由虚拟机管理程序写入。
上一节的图中描述了三种基本页面状态：Hypervisor、Guest-Valid 和 Guest-Invalid 状态。SEV-SNP 架构总共定义了八种主要页面状态，如下表所示。页面状态转换如下图所示，可以通过新的 CPU RMPUPDATE 指令（红色）、新的 PVALIDATE 指令（蓝色）或 AMD-SP 中的 VM 管理 API（绿色）进行。
| 状态 | 描述 | 补充 |
|---|---|---|
| Hypervisor | 未分配内存的默认状态 | 用于虚拟机管理程序内存、非 SNP-VM 内存和共享（C=0）内存 |
| GUEST-INVALID | 页面已分配给访客但尚未准备好使用 | 未经验证，SEV-SNP VM 无法使用 |
| GUEST-VALID | 页面已分配给访客并可用 | 页面可以被分配的 SEV-SNP VM 用作私有（C=1）内存 |
| PRE-GUEST | 页面不可变且未经验证 | 首次启动 SEV-SNP VM 时使用 |
| PRE-SWAP | 页面不可改变且已验证 | 用于将访客页面交换到磁盘 |
| FIRMWARE | 页面不可变且保留供 AMD-SP 使用 | 通常用作临时状态，直到 AMD-SP 配置页面 |
| METADATA | 页面是不可变的并用于元数据 | 将访客页面交换到磁盘时使用元数据 |
| CONTEXT | 页面是不可变的，用于上下文信息 | AMD-SP 使用上下文页面来识别单个虚拟机并保存每个虚拟机的数据 |
与之前的 SEV 技术一样，SEV-SNP 在 AMD-SP 中实现了虚拟机管理 API。虚拟机管理程序调用此接口来协助虚拟机生命周期任务和页面管理。出于安全原因，在发出必要的 API 调用之前，AMD-SP 将操作的任何页面都必须置于特殊状态（称为不可变状态）。处于不可变状态的页面不能由 CPU（虚拟机管理程序或客户机）上的任何软件写入，并且除了 AMD-SP 以外的任何对象都不能修改其 RMP 条目。
例如，“Metadata 元数据”页面是一种不可变页面。这些页面只能由 AMD-SP 写入，用于保存与已交换到磁盘的客户页面相关的元数据条目。由于 SEV-SNP 完整性保证，任何交换到磁盘的页面都必须确认其完整性，然后才能交换回内存。当页面交换到磁盘时，AMD-SP 会创建一个元数据条目，其中包含身份验证标签（来自 AES-GCM）以及来自页面 RMP 条目的数据，例如它所在的 GPA。由于元数据页面本身不可由虚拟机管理程序写入，因此可以保证此信息的完整性。当页面交换回内存时，AMD-SP 会验证内容是否未更改，并确保页面进入客户地址空间的位置与之前相同。元数据页面本身也可以以类似的方式交换到磁盘，允许将整个客户保存到磁盘（如果需要）。
虚拟机权限级别
虚拟机特权级别 (VMPL) 是 SEV-SNP 架构中的一项新可选功能，允许客户 VM 将其地址空间划分为四个级别。这些可用于在 VM 内提供硬件隔离的抽象层，以提供额外的安全控制，以及帮助管理与虚拟机管理程序的通信。
这些级别本质上是分层的，其中 VMPL0 是最高特权，而 VMPL3 是最低特权。启用此功能后，VM 的每个 vCPU 都分配有一个 VMPL。每个私有客户内存页面的 RMP 条目也增加了与每个 VMPL 相对应的页面访问权限，并且除了标准分页权限外还应用了这些权限。具体而言，可以将各个客户页面标记为可读、可写、主管模式可执行文件和用户模式可执行文件。默认情况下，当客户首次验证页面时，VMPL0 被授予对该页面的完全权限，而所有其他 VMPL 则不被授予任何权限。客户可以选择通过新的 RMPADJUST 指令修改 VMPL 权限。
RMPADJUST 指令允许给定的 VMPL 修改较低权限 VMPL 的权限。例如，VMPL0 可以向 VMPL1 授予页面的读取和写入（但不能执行）权限。这是受限制的，因此一个级别不能授予比当前更多的权限。VMPL 主要用于设置额外的页面权限检查，并且与其他 x86 安全功能正交。
RMP 页面权限检查是在表遍历结束时的 RMP 查找时执行的。页面权限检查本质上是限制性的，因此，例如，要使客户页面可写，必须在客户管理的页表（对应于活动 vCPU）、嵌套页表（由虚拟机管理程序管理）以及 RMP 表（由更高权限的 VMPL 管理）中将其标记为可写。
VMPL 在某些方面类似于嵌套虚拟化，因为客户机可能包含以高 VMPL 运行的自己的管理层，该管理层控制其其他页面上的权限。这可以实现诸如安全强制虚拟机管理程序的安全虚拟化等用例。在裸机系统上，可以使用标准虚拟机管理程序来强制某些页面是只读的、不可执行的等，而 SEVSNP 可以在云环境中启用相同的使用模型。在这种情况下，客户机内的 VMPL0 将强制执行所需的页面权限，因为云中的真正虚拟机管理程序被视为不受信任。
VMPL 在其他几个场景以及抽象层中都很有用。例如，APIC 仿真是一项传统上由虚拟机管理程序处理的任务。在 SEV-SNP 中，某些虚拟机可能需要一个更严格的环境，其中 APIC 仿真被移到客户机的信任域内。在这种情况下，VMPL0 可用于执行受信任的 APIC 仿真，同时允许客户机的其余部分在较低的 VMPL 中运行，而不知道仿真。
VMPL0 还可用作客户机与虚拟机管理程序通信的中介。以前，SEV 和 SEV-ES 技术需要能够了解这些安全功能的开明客户机操作系统。客户机操作系统需要执行诸如设置页表中的 C 位、处理 #VC 异常（在 SEV-ES 中）等操作。 对于 SEV-SNP，可以选择将这些任务委托给 VMPL0。在此使用模型中，VMPL0 可用于使用称为虚拟内存顶部 (vTOM) 的水印来配置另一个 vCPU 中的哪些客户内存是私有的 (C=1) 还是共享的 (C=0)。vTOM 以下的内存地址自动被视为私有的，而 vTOM 以上的内存则被视为共享的。使用 vTOM 以这种方式分离内存可避免使用 C 位标记来扩充标准 x86 页表，从而简化客户操作系统软件。
此外，VMPL0 还可用于处理另一个 vCPU 中发生的 #VC 事件。可以配置 SEV-SNP VM，以便当一个 vCPU（例如 RDMSR）中执行被拦截的指令时，该 vCPU 退出，并且可以调用 VMPL0。然后 VMPL0 可以直接从原始 vCPU 的加密保存区域查看截获的信息，执行任何必要的超调用，并代表原始 vCPU 仿真指令，如图所示。
虽然性能不如本机激活的客户机，但这种行为可以使 VMPL0 充当运行未激活(遗留)客户机vm的粘合逻辑。这有可能允许使用 SEV-SNP 来保护可能不容易升级到新操作系统的旧工作负载。
中断/异常保护
虽然几乎所有 VM 操作系统都支持中断和异常处理，但某些操作系统可能具有基于裸机硬件的关于中断和异常行为的内置假设。如果恶意虚拟机管理程序可以违反这些假设，则此行为可能会违反操作系统设计的假设。例如，操作系统可能不会期望在其 TPR 升高时采取低优先级中断，或者可能不会期望在执行 ADD 指令后采取 #UD 异常。
为了解决这些问题，SEV-SNP 增加了两种可选模式，VM 可以选择启用这些模式，以支持 VM 和虚拟机管理程序之间关于中断和异常的更严格的接口。第一种模式称为“限制注入”，它禁用虚拟中断排队并部分禁用中断注入接口。在此模式下，虚拟机管理程序仅允许注入单个新定义的异常向量 #HV，以充当门铃。限制注入假设 VM 和虚拟机管理程序将以半虚拟化方式传递事件，例如共享内存中的事件队列。 #HV 异常可以作为向客户机发出的信号，要求其重新扫描事件队列以获取新信息。
第二种模式称为**交替注入( Alternate Injection )**，允许标准的虚拟中断排队和注入接口，但这些只能由客户机本身控制。加密保存区域（称为虚拟机保存区域或 VMSA）中添加了新字段，允许中断排队和事件注入。在 VMSA 中，只有有权访问客户机 VMSA 数据的人（例如 VMPL0）才能操纵这些字段。在备用注入模式下，所有中断相关的安全敏感状态（例如 TPR）都保存到 VMSA，因此恶意虚拟机管理程序无法操纵它。
这两种模式结合起来，使 VMPL0 能够执行中断处理和 APIC 仿真。用于运行 VMPL0 的 vCPU 可以在启用限制注入的情况下运行，因此它们使用半虚拟化接口和 #HV 异常与虚拟机管理程序通信。用于运行其他 VMPL（客户机的主操作系统可能在其中运行）的 vCPU 可以在启用备用注入的情况下运行。这样，VMPL0 可以在安全的情况下向主操作系统注入事件和虚拟中断。从软件角度来看，主操作系统可以使用标准 APIC 或 x2APIC 接口，并且它所需的任何 APIC 访问都可以在 VMPL0 中捕获和仿真。
可信平台信息
平台特性和功能通常通过 CPUID 指令发现。虚拟机管理程序通常会出于各种原因捕获和模拟 CPUID 指令，包括限制客户机可以使用的功能以使其更易于迁移。在许多情况下，恶意虚拟机管理程序只能通过谎报 CPUID 特性来导致客户机拒绝服务。
但是，在某些情况下，不正确的 CPUID 信息可能会导致安全问题。例如，虚拟机管理程序谎报 x86 扩展保存区域（与 XSAVE/XRSTOR CPU 指令一起使用）的大小可能会导致客户机分配太小的内存区域，并在执行硬件 XSAVE 指令时发生缓冲区溢出。虽然在许多情况下客户机虚拟机可以尝试验证其收到的 CPUID（例如，通过检查报告的 XSAVE 缓冲区大小是否正确），但这可能具有挑战性，尤其是在启动过程中。
为了简化客户机必须执行的检查，SEV-SNP 支持通过 AMD-SP 过滤 CPUID 结果的可选功能。 AMD-SP 将验证虚拟机管理程序报告的 CPUID 结果是否不超过平台的功能，以及 x86 扩展保存区域大小等安全敏感信息是否正确。
CPUID 筛选可以即时进行，也可以作为客户机启动的一部分进行。对于即时筛选，在收到 CPUID 信息后，客户机可能会要求 AMD-SP 验证安全敏感信息是否正确。或者，在 VM 启动期间，可以创建一个特殊的“CPUID 页面”，其中包含来自 AMD-SP 的预先审查的 CPUID 信息，允许客户机从早期启动开始访问受信任的 CPUID 信息。除了安全优势之外，这个特殊页面还允许更快地访问 CPUID 信息，从而加快 VM 启动过程。
TCB 版本控制
在 SEV-SNP 架构中，有多个可升级的固件组件，包括 AMD-SP API、CPU 微码补丁等。由于这些固件组件在 SEV-SNP 威胁模型中被视为可信的，因此它们构成了架构的 TCB。随着错误修复或功能升级，可能会发布这些组件的新版本。如果在其中一个组件中发现安全错误，客户机所有者可能需要保证他们的 VM 运行在已修补的固件下，而不是易受攻击的版本。
之前的 SEV 和 SEV-ES 功能依赖于自我报告的 AMD-SP 版本号来实现 TCB 版本控制。客户机所有者可以指定最低版本的 AMD-SP 固件，并且 VM 无法在旧版本上加载。在 SEV-SNP 中，此检查已得到增强，具有很强的加密能力。在 SEV-SNP 中，所有 TCB 组件的版本号都与称为芯片认可密钥的融合密钥相结合，以创建版本化芯片认可密钥 (有版本的Chip Endorsement Key，VCEK)。VCEK 是私有 ECDSA 密钥，每个 AMD 芯片都独有，运行特定的 TCB 版本。VCEK 的构造使用加密哈希函数，因此给定的 TCB 版本无法伪装成较新的 TCB。VCEK 有多种用途，包括用于签署证明报告。
VM 启动和认证
与之前的 SEV 和 SEV-ES 架构一样，SEV-SNP VM 从初始未加密映像启动。此初始映像预计包含客户 VM 启动代码等内容，但由于它以未加密方式启动，因此不应包含任何机密。在启动过程中，虚拟机管理程序要求 AMD-SP 在客户中安装这组初始页面。AMD-SP 以加密方式测量这些页面的内容并将其转化为启动摘要。在 SEV-SNP 架构中，AMD-SP 还会测量与这些页面相关的元数据，即页面所在的 GPA 以及页面类型。这可确保启动摘要捕获初始客户内存的布局及其内容。
在 SEV-SNP 中，在启动过程结束时，客户所有者可以提供已签名的身份块 (IDB) 以与 VM 关联。IDB 包含允许客户所有者唯一标识 VM 的字段，并包含预期的启动摘要。 IDB 只能与符合预期启动摘要的虚拟机相关联，并包含在认证报告中。
虽然 SEV 和 SEV-ES 仅在客户机启动期间支持认证，但 SEV-SNP 支持更灵活的认证。客户机虚拟机可以随时通过受保护的路径从 AMD-SP 请求认证报告。作为 SEV-SNP VM 启动的一部分，AMD-SP 会创建一组私有通信密钥，客户机可以使用这些密钥直接与 AMD-SP 通信。客户机可以使用此路径请求认证报告、加密密钥等。
证明报告包含启动时的 IDB 信息、系统信息以及客户虚拟机作为报告请求的一部分提供的任意数据块。证明报告由 AMD-SP 固件使用 VCEK 签名。证明报告使第三方（例如客户所有者）能够验证某些数据是否来自某个虚拟机。
例如，虚拟机可以发布公钥并向 AMD-SP 索取包含此公钥哈希值的证明报告，如图所示。然后，第三方可以通过证明报告验证此公钥是否与此虚拟机相关联。认证报告还证明 VM 在启用了适当的安全特性的情况下运行，并且它在一个真正的 AMD 平台上启动。由于认证报告是由 VCEK 签名的，因此该报告的验证既证明了平台的真实性，也证明了使用的 TCB 版本的真实性(因为 VCEK 是从 TCB 版本派生出来的)。在成功验证之后，第三方(例如客户所有者)可以选择向VM提供秘密，例如磁盘解密密钥或操作所需的其他密钥。
除了远程认证之外，SEV-SNP 还支持生成客户密钥材料的其他使用模型。SEV-SNP VM 可以直接从 AMD-SP 请求密钥，用于各种目的，例如数据密封。这些密钥可能来自不同的来源，VM 可以根据其用例的需要选择使用哪些来源。例如，可以请求特定于某个 TCB 级别的当前部分并特定于 IDB 签名密钥的本地密封密钥。通过这些控制，VM 可以请求保证无法由恶意行为者或其他设备派生的密钥。
虚拟机迁移
VM 迁移，特别是实时 VM 迁移，是现代云架构的标准功能。实时 VM 迁移允许在需要负载平衡、主机系统维护和其他目的时不间断地将一个 VM 移动到另一个物理系统。所有 SEV 技术都支持 VM 迁移，但 SEV-SNP 增强了与迁移相关的灵活性。
在 SEV 和 SEV-ES 中，VM 迁移由客户所有者提供的策略决定。此策略指示 VM 是否可迁移，如果可以，可以迁移到哪种类型的系统。AMD-SP 负责执行此迁移策略，并通过在开始迁移之前对目标计算机上的 AMD-SP 进行身份验证来实现。
在 SEV-SNP 中，迁移策略执行的角色已被转移到一个称为迁移代理（Migration Agent，MA）的新实体。MA 本身是一个 SEV-SNP VM，它在与主 VM 相同的物理系统上运行。启动 VM 时，可以选择将其与已经运行的 MA 相关联。由于 MA 是客户机 TCB 的一部分，因此有关 VM 的 MA 绑定的信息存在于其认证报告中。每个 VM 只能与一个 MA 关联，但一个 MA 可以管理任意数量的 VM 的迁移。
MA 负责确定主 VM 可以迁移到哪些系统。虽然 MA 架构的细节超出了本白皮书的范围，但 MA 可以使用其想要的任何方式实施复杂的迁移策略。
在典型的云场景中，MA 本身不可迁移。相反，MA 的单独实例在每台物理机器上运行。当 VM 即将迁移时，源机器上的 MA 会对目标机器上的 MA 进行身份验证并建立受保护的网络连接。如果成功，MA 将传输所需的客户机信息，以便可以在新机器上重建客户机。
值得注意的是，由于 MA 的灵活性，源计算机和目标计算机不需要同时在线。当 VM 暂停时，其状态可以导出到其 MA。MA 可以选择立即将该状态移至另一个 MA 进行实时迁移，也可以选择保留该状态或将其放入长期存储中。稍后，可以根据 MA 的需要在同一台计算机或另一台计算机上重建此 VM。
侧信道
最近，许多安全研究都集中在 CPU 侧信道攻击上，这种攻击利用 CPU 的内部结构来泄露信息。推测性侧信道攻击（例如 Spectre）已被证明利用硬件分支预测等标准技术在某些情况下造成数据泄露。AMD 增加了硬件功能，以帮助软件抵御某些攻击，例如 Spectre Variant 2。
Spectre Variant 2 证明，在某些软件情况下，如果攻击者能够影响另一个实体的分支预测，则可以利用间接分支预测器 (BTB)。在最近的 CPU 设计中，AMD 增加了对 SPEC_CTRL MSR 和 PRED_CMD MSR 的支持，从而可以对 BTB 结构进行更多的软件控制。在 SEV-SNP 架构中，SPEC_CTRL MSR 被虚拟化，允许客户机独立于虚拟机管理程序选择自己的推测策略。这允许客户机使用 IBRS 等模式。
在传统虚拟化中，虚拟机管理程序会采取措施保护自己免受基于客户的攻击。这可能包括 retpoline（回跳线：一种软件编程技术，用于减轻现代处理器中分支预测器的安全漏洞，如Spectre漏洞。）或使用 IBRS 设置运行等技术。当虚拟机管理程序不受信任时，客户机还可能担心基于虚拟机管理程序的攻击。例如，恶意虚拟机管理程序可能会尝试毒害客户机将使用的 BTB 条目，或者可能尝试在 SEV-SNP 客户机运行之前使用另一个 VM 毒害 BTB。
为了防止此类攻击，SEV-SNP VM 可以选择额外的保护，即CPU 硬件将阻止 VM 推测性地使用由其他实体安装的 BTB 条目。此功能跟踪虚拟机管理程序或其他软件安装 BTB 条目的时间，并在需要时自动执行 BTB 刷新，以便 SEV-SNP VM 不会推测性地使用这些 BTB 条目。
同步多线程（Simultaneous Multi-Thread，SMT）是 CPU 硬件的另一个领域，一直是侧信道研究的重点。由于 SMT 设计中的共享硬件资源，因此可以有更多的观察渠道。认为自己对此类观察特别敏感的 SEV-SNP VM 可以选择一项政策，限制它们仅在禁用 SMT 的系统上运行。
虽然 SEV-SNP 在防止投机性侧信道攻击和 SMT 方面为客户端提供了几种选择，但它无法防止所有可能的侧信道攻击。例如，传统的针对 PRIME+PROBE 等软件的侧信道攻击就不受 SEV-SNP 的保护。这些类型的攻击需要专门针对易受这些类型的侧信道攻击的软件算法，通常是因为它们涉及基于秘密值改变其缓存或 TLB 访问模式的代码路径。现代加密库特别注意避免此类行为，因为这些类型的攻击即使在非虚拟化平台上也可能发生。因为 SEV-SNP 硬件没有被设计成明确地防止这种攻击，所以 VM 所有者有责任遵循标准的安全实践，并确保他们的库和软件更新到不使用可能容易受到这些攻击的算法。
另一类不属于 SEV-SNP 范围的旁道攻击包括应用程序指纹攻击，例如性能或页表错误监控。如前所述，SEV-SNP 主要侧重于保护虚拟机内部的数据，这些类型的攻击通常仅试图确定正在运行的应用程序，不会直接破坏客户虚拟机数据的机密性或完整性。SEV 的未来版本可能会针对其中一些攻击媒介提供额外的保护。
结论
SEV-SNP 代表了在非受信任托管环境中运行的虚拟机的增强安全性和隔离性。在提供数据机密性保护以抵御可能存在错误的虚拟机管理程序的 SEV 和 SEV-ES 功能的基础上，SEV-SNP 增加了能够保护虚拟机免受恶意虚拟机管理程序攻击的完整性保证。除了完整性保护之外，SEV-SNP 还以多个 VMPL、新的证明和密钥派生架构以及任意灵活的迁移策略的形式提供了新的架构灵活性。
SEV-SNP 还通过提供针对恶意中断注入、某些推测性侧信道攻击和 TCB 回滚攻击的可选保护来提高安全标准。这些功能与以前的 SEV 和 SEV-ES 功能一样，旨在在客户操作系统级别启用，这意味着无需更改虚拟机内的应用程序。
虚拟机隔离对于现代云计算环境来说是一项艰巨的任务。SEV-SNP 是第一个旨在支持独立虚拟机的机密性和完整性保护的 x86 架构，可为各种工作负载提供更安全的云计算。AMD 认为，安全的云计算是未来数据中心的关键工作负载，而 SEV-SNP 是实现这一目标的下一步。