【TEE】【AMD SEV-SNP 白皮书】通过完整性保护加强VM隔离

介绍

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能够读取一个私有(加密)的内存页，那么它必须始终读取上一次写入的值。这意味着，如果VM向内存位置X写入一个值A，那么每当它以后读取X时，它必须要么看到值A，要么必须得到一个异常，表明该内存不能被读取。SEV - SNP的设计是为了使VM不能看到与内存位置X不同的值。

在典型的用例中，虚拟机既要执行自己的任务，又要通过I / O与外部实体进行通信。这可能包括通过网络链路、与存储服务器或其他组件进行通信。在SEV架构中，这种通信是使用共享(未加密)内存完成的。VM希望提供的任何传出数据都被放置在内存的共享页中，任何传入数据也必须被放置在共享页中。由于共享内存不使用虚拟机的特定密钥进行加密，因此I/O流的安全性需要使用合适的软件加密协议，如HTTPS。

MD SEV虚拟机使用客户页表中的加密位( en Crypted bit，C-bit )控制内存页是私有还是共享。共享(未加密)内存被VM标记为C = 0，表明它不必用VM的内存加密密钥进行加密。私有(加密)内存页用于该VM的独占使用，并标记为C = 1。在一个典型的虚拟机中，大多数页面被标记为私有的，只有用于外部通信的选择页面被标记为共享的。与SEV的机密性保证一样，SEV - SNP的完整性保证只适用于私有的客户页面。

威胁模型细节

与之前的SEV和SEV - ES特征一样，在SEV - SNP下，AMD片上系统( SOC )硬件、AMD安全处理器( AMD-SP )和VM本身都被视为完全可信。VM负责保护自身及其接口，对于它使用的任何I/O数据，如网络流量、硬盘数据等，都应该遵循标准的最佳实践。为此，AMD强烈建议使用带有受保护VM的全磁盘加密( Full Disk Encryption，FDE )解决方案，因为所有的SEV技术只保护正在使用的数据。FDE保护静态数据并且存在许多流行的商业解决方案。

在SEV - SNP下，所有其他CPU软件组件和PCI设备被视为完全不可信，如图2所示。包括主机系统上的BIOS、虚拟机管理程序、设备驱动程序、其他VM等。完全不可信是指这些组件被认为是恶意的，可能与其他不可信组件合谋，以损害SEV - SNP VM的安全保证。

SEV - SNP威胁模型包含了比以往AMD SEV技术更多的用于抵御额外威胁的特征。SEV和SEV - ES采用"良性但脆弱"的管理程序威胁模型。在这种威胁模型中，管理程序并不被认为是100 %安全的，但它被信任以良性的意图行事。也就是说，管理程序虽然没有积极地试图对其下方的SEV虚拟机进行损害，但其本身可能存在可利用的漏洞。通过阻止或增加某些攻击的难度，SEV和SEV - ES技术有助于限制某些类别管理程序bug的潜在暴露或显著提高利用难度。SEV - SNP解决了额外的攻击向量和VM安全的潜在威胁。在表1中总结了各种SEV技术所面临和未解决的威胁。


机密性：机密性威胁是基于硬件的内存加密来处理的。SEV - ES技术为VM寄存器状态增加了机密性保护，在VM退出到虚拟机管理程序时对该状态进行加密。这种保护作用同样存在于SEV - SNP中。

完整性：SEV - SNP技术旨在防止完整性攻击，包括数据重放、损坏、重新映射和基于别名的攻击。

可用性：任何虚拟化平台都有两个方面的可用性。首先，确保管理程序保留对系统的控制，并且客户VM不能拒绝管理程序的运行，否则将导致物理机器不可用。所有的SEV技术都支持这种级别的可用性，并保证管理程序在需要时总能重新获得控制，或者在没有该虚拟机同意的情况下随时终止客户。可用性的第二个方面是客户是否享有任何可用性保证，如最低运行时间。这不是任何SEV技术威胁模型的一部分，因为恶意管理程序总是可以选择永远不运行某个客户虚拟机。

物理访问攻击：虽然某些物理攻击，如DRAM冷启动攻击(对DRAM芯片进行离线分析)可以被防御，但在线DRAM完整性攻击，如在VM积极运行时攻击DDR总线，则不在考虑范围之内。这些攻击是非常复杂的，需要很大程度的本地访问和资源来执行。

杂项：存在其他几种类型的针对安全虚拟机的潜在攻击，其中一些在这个威胁模型范围内的。例如，SEV - SNP包含了防止可信计算基础( TCB )回滚攻击的特征。

此外，SEV - SNP可选地支持限制中断和异常注入VM的能力。它还可以支持分支目标缓冲区( Branch Target Buffer，BTB )保护以抵御某些类型的侧信道攻击。这两种保护在本白皮书后面进行了讨论。

最后，还有某些类别的攻击不属于这三个特征中的任何一类。针对CPU数据结构的架构侧信道攻击并不能通过任何硬件手段进行针对性的防范。与标准的软件安全实践一样，对这种侧信道攻击(例如,密码学库)敏感的代码应该以一种有助于防止这种攻击的方式写入。指纹识别攻击防护在当前这些技术的产生中也是不被支持的。指纹攻击试图通过监视虚拟机的访问模式、性能计数器信息等来确定虚拟机正在运行的代码。虽然指纹有时可以提供VM内部正在运行的代码的信息，但通常最敏感的信息是数据本身(例如,数据库中的数据)，而不是正在运行的代码(例如,正在使用哪个版本的数据库软件)。因此，当前的SEV技术主要侧重于保护敏感的VM数据内容。在未来的SEV技术中，可以针对某些指纹攻击提供额外的保护。

完整性威胁

上一节重点介绍了四类独特的完整性威胁：重放保护、数据损坏、内存别名和内存重新映射。防范这些威胁需要执行不同的安全属性，如表2所示。在基于重放保护和数据损坏的攻击中，这些攻击依赖于不可信代码能够写入受保护VM的内存。SEV - SNP通过强制只有内存页(例如,页面被分配到的SEV - SNP VM)的所有者可以写入该页来解决这个问题。这种强制执行使用下一节中描述的反向映射表( Reverse Map Table，RMP )机制来完成。

内存别名攻击涉及管理程序恶意地同时将两个不同的访客页映射到同一个物理内存页。访客自然希望其访客物理地址空间中的不同页面映射到不同的内存，因此任何混叠都可能导致无意的数据损坏。解决这一威胁需要确保内存的每个物理页面一次只能映射到一个访客页面。再次，RMP结构被用于强制实施这一属性。

内存重映射( Memory Re-Mapping )，涉及到虚拟机管理程序将单个访客页恶意地重映射到多个不同的物理内存页。在这种威胁下，客人可能会看到一个不一致的内存视图，其中只有它写的数据子集出现在内存中。应对这种威胁需要确保每个客户页面一次只映射到一页物理内存，并且这种映射不能被改变，除非像AMD - SP这样的可信实体。SEV - SNP使用一种名为Page Validation的机制来应对这一威胁。页面验证依靠新的RMP机制与新的VM代码相结合来管理访客内存与系统内存之间的内部映射关系。

反向映射表 RMP

如前所述，SEV - SNP的许多完整性保证都是通过一种名为反向映射表( Reverse Map Table，RMP )的新结构来实现的。RMP是一个在整个系统中共享的单一数据结构，每个4k页的DRAM有一个入口，这些入口可能会被VM使用。RMP的目标很简单：它跟踪每一页内存的所有者。内存页可以是管理程序拥有的，也可以是特定虚拟机拥有的，还可以是AMD - SP拥有的。对内存的访问是受控制的，因此只有该页的所有者才能写入。RMP与标准的x86页表一起使用，以强制执行内存限制和页面访问权限。

RMP由系统物理地址索引，并在CPU和IOMMU表table-walks的末尾进行检查。例如，在native (非VM )模式下，使用标准的x86页表将虚拟地址转换为物理地址。在翻译之后，最终的物理地址被用来索引RMP。RMP条目被读出并检查。如果RMP表项表明该页面是管理程序拥有的页面，则检查通过，并创建新的TLB表项。如果RMP项表明该页面不是管理程序拥有的页面，则table-walks失败（#PF）并拒绝访问。

当在SEV - SNP VM中运行时，RMP检查稍微复杂一些。与本地模式一样，虚拟地址首先被翻译成系统物理地址。在这种情况下，使用AMD - V 2级分页将客户虚拟地址( GVA )转换为客户物理地址( GPA )，最后转换为系统物理地址( SPA )。使用SPA对RMP进行索引，并对条目进行检查。RMP表项包含了应该映射的GPA，并且硬件验证了这个GPA与当前table-walks的GPA相匹配。如果这个或任何其他检查失败，则产生异常，并拒绝访问。

并非每个内存访问都需要RMP检查。特别地，来自管理程序的读访问不需要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位，当为客户创建一个新的RMP条目时，该位被CPU硬件自动清空为0。被分配给客户机但具有Validated bit clear的页面不能被管理程序使用，也不能作为私人访客页面使用，因为该页面没有被验证。客户机只能通过新的CPU指令PVALIDATE设置Validated bit后才能使用该页面。只有访客才能使用PVALIDATE，每个访客VM只能验证自己的内存。

因此，向客户VM添加新页面需要一个2步的过程，如图4所示。首先，管理程序使用新的RMPUPDATE指令将页面分配给客户。这将页面过渡到Guest - Invalid状态。其次，客户验证页面使用新的PVALIDATE指令将页面过渡到Guest - Valid状态，从那里可以使用它。

为了满足SEV - SNP所期望的完整性，客户虚拟机不应该多次验证与同一个GPA对应的内存。这可以简单地通过客户虚拟机在启动时验证其所有内存，并拒绝再验证额外的内存来实现。或者，客户虚拟机可以跟踪其已验证的内存位置，并拒绝对同一内存位置进行两次验证。假设客户虚拟机正确验证其内存，这保证了GPAs和SPAs之间的内射映射。客户只对每个GPA进行一次验证，通过构建RMP表，保证每个SPA只能映射到一个GPA。

当正确执行时，页面验证可以像图5所示的那样阻止重映射攻击。在这个例子中，GPA A最初被映射到SPA X，客户做一个PVALIDATE来验证这个转换，这导致Validated bit被设置在SPA X对应的RMP条目中。如果管理程序随后恶意试图将A重新映射到不同的SPA Y，它将首先为SPA Y创建一个RMP条目，试图使用RMPUPDATE指令映射相同的GPA A。然后，管理程序恶意修改嵌套页表( NPT )，将GPA A重新映射到Y。然而，当客户访问Y时，它将获得# VC ( VMM Communication )异常。出现此异常是因为SPA Y对应的RMP条目中Validated bit是clear的(当RMPUPDATE被执行为客户分配一个新的页面时,它最初清除了Validated bit)。由于客户知道自己已经验证了GPA A，所以知道自己不应该收到验证错误，因此受到攻击，管理程序的行为不正确。作为回应，客户机可以终止或采取其他措施来保护自己。

页表状态

如图所示，SEV - SNP中的RMP跟踪每一页内存的状态。这些状态决定了内存可以用于什么，谁可以读写方法它，以及页面以后可以过渡到什么状态。例如，处于管理程序状态的页面可以被管理程序读/写，也可以被SEV - SNP虚拟机以C = 0 (共享页面)的方式访问内存。

相反，处于Guest - Valid状态的页面可以被SEV - SNP VM读取/写入，但不能被管理程序写入。图4描述了三种基本的页面状态：管理程序状态、Guest - Valid状态和Guest - Invalid状态。总的来说，SEV - SNP架构定义了8个主要的页面状态，如表3所示。

与以往的SEV技术一样，SEV - SNP在AMD - SP中实现了一个VM管理API。管理程序调用该接口来辅助VM生命周期任务和页面管理。出于安全的考虑，AMD - SP将要操作的任何页面都必须在发出必要的API调用之前被放置到特殊的状态中，称为不可变状态。处于不可变状态的页面不能被CPU (管理员或客人)上的任何软件写入，也不能被AMD-SP以外的任何对象修改其RMP条目。当AMD - SP在其中一个Immutable状态中处理完一个页面时，它可能会根据特定的API调用将其转换到另一个状态。

例如，"元数据"页面是不可变页面的一种。这些页面仅可由AMD SP写入，用于保存与已交换到磁盘的客户页面相关的元数据条目。由于SEV - SNP的完整性保证，任何被交换到磁盘的页面必须经过完整性确认后才能被交换回内存。当一个页面被交换到磁盘时，AMD - SP会创建一个包含认证标签(来自AES - GCM)的元数据项，以及来自该页面RMP条目的数据，例如它所在的GPA。**由于元数据页面本身是管理程序不可写的，因此保证了这些信息的完整性。**当页面被交换回内存时，AMD - SP验证内容是否被修改，并确保页面在之前相同的位置进入客户机地址空间。元数据页本身也可以以类似的方式交换到磁盘中，允许在需要时将整个客户机保存到磁盘中。

虚拟机特权级别

虚拟机权限级别( VMPLs )是SEV - SNP架构中的一个新的可选特性，它允许客户虚拟机将其地址空间划分为4个级别。这些可用于在VM内提供硬件隔离的抽象层，用于额外的安全控制，以及协助管理与虚拟机管理程序的通信。

这些层次在本质上是分层的，其中VMPL0是最高特权级，VMPL3是最低特权级。当该功能被启用时，VM的每个vCPU被分配一个VMPL。私有访客内存的每个页面的RMP条目也增加了与每个VMPL对应的页面访问权限，并且除了标准的分页权限外还被应用。具体来说，个人客户页面可以被标记为可读的、可写的、管理员模式可执行的和用户模式可执行的。默认情况下，当一个页面被访问者首次验证时，VMPL0被授予该页面的全部权限，其他所有VMPL均不授予任何权限。客人可以选择通过新的RMPADJUST指令修改VMPL权限。

RMPADJUST指令允许给定的VMPL修改权限较小的VMPL的权限。例如，VMPL0可以将页面上的(但不执行)权限授予VMPL1。这是受到限制的，因此一个级别不能授予比它当前拥有的更多的权限。VMPL主要用于设置额外的页面权限检查，否则与其他x86安全特性正交。

RMP页面权限检查在表遍历结束时的RMP查找时执行。页面权限检查在本质上是限制性的，因此对于要可写的客户页面，必须在客户管理的页表(对应于主动vCPU)、嵌套页表(由管理程序管理)以及RMP表(由较高特权的VMPL管理)中标记可写。

MPL在某些方面类似于嵌套虚拟化，客户机可能包含自己的管理层，该管理层运行在VMPL较高的位置，并控制其他页面的权限。这使得诸如安全措施管理程序的安全虚拟化等用例成为可能。而在裸机系统上，标准的管理程序可以用来强制某些页面是只读的，不可执行的等，SEV SNP可以在云环境中实现相同的使用模型。在这种情况下，当云中的真实管理程序被视为不可信时，客户机内部的VMPL0将执行所需的页面权限。

VMPL在几个额外的场景以及抽象层中都很有用。例如，APIC仿真是传统上由管理程序处理的任务。在SEV - SNP中，某些虚拟机可能希望在客户机的信任域内移动APIC模拟，这种环境的限制性更强。在这种情况下，VMPL0可以用来执行可信的APIC仿真，同时允许其余的客户机运行在较低的VMPL中，而不知道仿真。

VMPL0也可以作为客户与管理程序通信的中介。在此之前，SEV和SEV - ES技术都需要一个了解这些安全特性的开明客户操作系统。客户机操作系统需要完成页表中C位的设置、处理# VC异常(在SEV - ES中)等操作。在SEV - SNP的情况下，可以选择将这些任务委托给VMPL0。

在这个使用模型中，VMPL0可以用来配置另一个vCPU中的哪些访客内存是私有的( C = 1 )，而哪些访客内存是共享的( C = 0 )。vTOM以下的内存地址被自动视为私有，vTOM以上的内存地址被视为共享。使用vTOM以这种方式分离内存，避免了对标准x86页表增加C位标记的需要，简化了客户操作系统软件。

此外，VMPL0还可以用来处理发生在另一个vCPU中的# VC事件。可以配置一个SEV - SNP VM，使得当一个vCPU (例如, RDMSR)中执行被拦截的指令时，vCPU退出并调用VMPL0。VMPL0可以直接从原始vCP的加密保存区域查看执行截获的信息，执行任何必要的超调用，并模拟代表原始vCPU的指令，如图8所示。

中断、异常保护

虽然几乎所有的VM操作系统都支持中断和异常处理，但一些操作系统可能内置了基于裸机硬件的中断和异常行为假设。如果恶意管理程序能够违反这些假设，那么这种行为就有可能违反操作系统设计的假设。

为了解决这些问题，SEV - SNP增加了VM可以选择的两种可选模式，以支持VM和管理程序之间关于中断和异常的更严格的接口。第一种模式称为限制注入，它禁用虚拟中断排队，部分禁用中断注入接口。在这种模式下，管理程序只允许注入一个新定义的异常向量# HV来充当门铃。受限注入假设VM和管理程序将以半虚拟化的方式进行事件通信，例如共享内存中的事件队列。# HV异常可以作为客户机向重审事件队列发送新信息的信号。

第二种模式称为交替注入( Alternate Injection )，允许标准的虚拟中断排队和注入接口，但这些只能由客户机自己控制。在加密保存区(称为虚拟机保存区域( VMSA ))中增加了新的字段，允许中断排队和事件注入。在VMSA中，这些字段只能由访问客户机VMSA数据的人员进行操作，如VMPL0。在交替注入模式下，所有与中断相关的安全敏感状态(如TPR)被保存到VMSA中，因此不能被恶意的管理程序操作。

这两种模式的结合使VMPL0能够执行中断处理和APIC仿真，用于运行VMPL0的vCPU可以在启用限制注入的情况下运行，因此它们使用半虚拟化接口和# HV异常与管理程序通信，用于运行其他VMPL的vCPU可以在启用交替注入的情况下运行(其中,推测客户机的主OS运行)。这样，VMPL0可以在安全的情况下向主操作系统注入事件和虚拟中断。从软件的角度来看，主操作系统可以使用标准的APIC或x2APIC接口，它所需要的任何APIC访问都可以在VMPL0中捕获和仿真。

可信平台信息

平台功能和能力传统上是通过CPUID指令发现的。虚拟机管理程序通常会捕获和模拟CPUID指令，原因有很多，包括限制客户可能使用的特性以使其更容易迁移。在许多情况下，恶意虚拟机管理程序只能通过谎报CPUID特征来对客户造成拒绝服务。

然而，在某些情况下，错误的CPUID信息可能会导致安全问题。例如，一个大小约为x86扩展保存区域(配合XSAVE / XRSTOR CPU指令使用)的虚拟机管理程序在执行硬件XSAVE指令时可能会导致客户机分配的内存区域过小和缓冲区溢出。虽然在许多情况下，客户虚拟机可以尝试验证其接收到的(例如,通过检查报告的XSAVE缓冲区大小是否正确)的CPUID，但这可能是具有挑战性的，尤其是在启动过程中。

为了简化客户机必须做的检查，SEV - SNP支持通过AMD - SP过滤CPUID结果的可选功能。AMD - SP将验证管理程序报告的CPUID结果不大于平台的能力，以及安全敏感信息，如x86扩展保存区域大小是否正确。

TCB版本控制

在SEV - SNP架构中，有多个可升级的固件组件，包括AMD - SP API、CPU微码补丁等。由于这些固件组件在SEV - SNP威胁模型中被认为是可信的，因此它们构成了该架构的TCB。随着bug的修复或功能的升级，这些组件的新版本可能会被发布。如果在其中一个组件中发现安全漏洞，客户机所有者可能需要保证他们的VM在修补固件下运行，而不是易受攻击的版本。

之前的SEV和SEV - ES特征都依赖于一个自报的AMD - SP版本号来实现TCB版本控制。客户机所有者可以指定AMD - SP固件的最小版本，并且VM不能加载到旧的固件上。在SEV - SNP中，这种检查被增强为密码学上的强。在SEV - SNP中，所有TCB组件的版本号与一个称为芯片背书密钥的融合秘密相结合，创建一个有版本的芯片背书密钥(有版本的Chip Endorsement Key，VCEK )。VCEK是每个AMD芯片所独有的私有ECDSA密钥，运行特定的TCB版本。VCEK的构造使用了密码学哈希函数，使得给定的TCB版本不能假冒为更新的TCB。VCEK有多种使用方式，包括用于签发认证报告。

虚拟机启动和验证

与之前的SEV和SEV - ES架构一样，SEV - SNP虚拟机从初始未加密镜像开始。这个初始映像预计包含客户VM启动代码之类的东西，但由于它开始未加密，因此不应该包含任何秘密。在启动过程中，管理程序要求AMD - SP在客户机安装这组初始页面。AMD - SP对这些页面的内容进行密码学度量，形成一个启动摘要。在SEV - SNP架构中，AMD - SP还度量了与这些页面相关的元数据，即页面所在的GPA以及页面所在的类型。

在SEV - SNP中，在启动过程结束时，客户机所有者可以提供一个签名的身份块( Identity Block，IDB )来关联VM。IDB包含允许客户所有者唯一识别VM的字段，并包含预期的启动摘要。DB只能与与预期发布摘要相匹配的VM相关联，并作为认证报告的一部分纳入。

而SEV和SEV - ES只支持客户启动期间的认证，SEV - SNP支持更灵活的认证。客户VM可以通过AMD - SP的一条受保护的路径随时向AMD - SP请求认证报告。作为SEV - SNP虚拟机启动的一部分，由AMD - SP创建一组私有通信密钥，客户机可以使用这些密钥直接与AMD - SP通信。访客可以使用该路径请求认证报告、加密密钥等。

测试报告包含了来自启动的IDB信息，系统信息，以及作为报告请求的一部分由客户VM提供的任意数据块。认证报告由AMD - SP固件使用VCEK签署。认证报告使第三方(如客人所有者)能够验证某些数据来自某个VM。

例如，VM可以发布一个公钥，并向AMD - SP请求包含该公钥哈希的认证报告，如图10所示。然后，第三方可以通过认证报告来验证该公钥与该VM相关联。认证报告也证明VM运行时启用了相应的安全功能，并在一个真实的AMD平台上启动。由于该认证报告是由VCEK签发的，因此该报告的验证既证明了平台的真实性，也证明了使用(由于VCEK源自TCB版本)的TCB版本的真实性。在认证成功后，第三方(如客户所有者)可以选择向虚拟机提供秘密，如磁盘解密密钥，或其他操作所需的密钥。

除了远程证明，SEV-SNP VM可以直接从AMD - SP请求密钥，用于数据密封等多种目的。这些密钥可能来自不同的源，VM可以根据需要为其用例选择使用哪个源。例如，可以请求特定于某个TCB级别的当前部分和特定于IDB签名密钥的本地密封密钥。通过这些控制，VM可以请求保证不能由恶意参与者或其他设备派生的密钥。

虚拟机迁移

虚拟机迁移，特别是动态虚拟机迁移，是现代云架构的标准特征。当需要进行负载均衡、主机系统维护和其他目的时，实时虚拟机迁移允许将一个虚拟机不间断地迁移到另一个物理系统。所有的SEV技术都支持虚拟机迁移，但SEV - SNP增强了迁移的灵活性。

在SEV和SEV - ES中，VM迁移由客户所有者提供策略决定。该策略表明VM是否是可移植的的，如果是，那么是什么类型的系统。AMD - SP负责执行该迁移策略，并通过在迁移开始前对目的机器上的AMD - SP进行认证来实现。

在SEV - SNP中，迁移政策执行的角色被卸载到一个名为"迁移代理" ( Migration Agent，MA )的新实体。MA本身是一个SEV - SNP VM，运行在与主VM相同的物理系统上。当一个VM启动时，它可以有选择地与一个已经运行的MA相关联。VM的MA绑定信息存在于其认证报告中，因为MA是客户TCB的一部分。每个VM只能与单个MA相关联，但单个MA可以管理任意数量的VM的迁移。

MA负责确定主虚拟机可以迁移到哪些系统。虽然MA架构的细节超出了本白皮书的范围，但MA可以利用它想要的任何手段来实施复杂的迁移政策。

在典型的云情景下，MA本身并不具有可迁移性。取而代之的是，MA的一个单独的实例在每个物理机器上运行。当VM即将迁移时，源机器上的MA对目标机器上的MA进行身份验证，建立受保护的网络连接。如果成功，MA传输所需的客户机信息，从而可以在新机器上重新构造客户机。值得注意的是，由于MA的灵活性，不要求源机器和目的机器同时在线。当一个VM被暂停时，它的状态可以输出给它的MA。MA可以选择立即将该状态转移到另一个MA上进行动态迁移。之后，该VM可以根据MA的要求在同一台机器或另一台机器上重构。

侧信道

近来大量的安全研究集中在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被虚拟化，允许客户机独立于管理程序选择自己的推测执行策略。

在传统的虚拟化中，管理程序采取步骤来保护自己免受基于客户的攻击。这可能包括retpoline或使用IBRS集运行等技术。当管理程序不被信任时，客户机也可能担心基于管理程序的攻击。例如，一个恶意的管理程序可能企图毒化客户将使用的BTB条目，或者可能在SEV - SNP客户运行之前尝试使用另一个VM来毒化BTB。

为了防止这些攻击，SEV-SNP虚拟机可能会选择额外的保护，这样CPU硬件就可以防止虚拟机投机性地使用另一个实体安装的BTB条目。该特性在虚拟机管理程序或其他软件安装BTB条目时进行跟踪，并在需要时自动执行BTB刷新，从而使SEV - SNP虚拟机不会猜测性地使用这些BTB条目。

同时多线程( Simultaneous Multi-Thread，SMT )是CPU硬件的另一个领域，一直是侧信道研究的热点。由于SMT设计中共享的硬件资源，使得更多的侧信道观测成为可能。相信自己对这种观察特别敏感的SEV - SNP虚拟机可能会选择一种策略，限制它们只能在SMT禁用的系统上运行。

结论

SEV - SNP表示在不可信的托管环境中运行的虚拟机的安全性和隔离性的增强级别。SEV - SNP在SEV和SEV - ES特征的基础上，增加了针对可能存在漏洞的虚拟机管理程序的数据机密性保护，从而增加了能够保护虚拟机免受恶意虚拟机管理程序攻击的完整性保证。除了完整性保护，SEV - SNP还提供了新的架构灵活性，包括多个VMPL，新的证明和密钥派生架构，以及任意灵活的迁移策略。

SEV - SNP还通过提供可选的保护来防止恶意中断注入、某些推测的侧信道攻击和TCB回滚攻击，从而提高了安全性。与以前的SEV和SEV - ES功能一样，这些功能被设计为在客户操作系统级别启用，这意味着不需要对虚拟机内部的应用程序进行任何更改。

对于现代云计算环境，虚拟机隔离是一项具有挑战性的任务。SEV - SNP是第一个同时支持对孤立虚拟机的机密性和完整性保护的x86架构，能够为各种工作负载提供更安全的云计算。AMD认为，安全的云计算是未来数据中心的关键工作负载，SEV - SNP是实现这一目标的下一步。