AMD MEMORY ENCRYPTION白皮书-翻译

AMD MEMORY ENCRYPTION白皮书原文链接

介绍

在现代计算系统中，对实用安全性的需求比以往任何时候都更为迫切。系统复杂性的增加、云计算的发展以及新技术的出现，都促成了一个既难以保护又至关重要的计算环境。AMD 认识到这些严峻的挑战，并开发了新的内存加密技术，旨在满足各种系统的需求。

安全内存加密（SME） 定义了一种简单且高效的主内存加密架构功能。虽然内存加密技术以前已在各种专用产品和行业中使用过，但 SME 是一种通用机制，它灵活、集成于 CPU 架构中，可扩展用于从嵌入式系统到高端服务器的各种工作负载，并且不需要修改应用软件。

主内存加密可以用来保护系统免受各种攻击。虽然当今的数据通常在存储到磁盘上时会被加密，但在 DRAM 中却是明文存储的。这可能会使数据容易受到未经授权的管理员或软件的窥探，或者受到硬件探测的攻击。新的非易失性内存技术（NVDIMM）加剧了这个问题，因为 NVDIMM 芯片可以在数据完整的情况下从系统中物理移除，类似于硬盘。没有加密的话，任何存储的信息如敏感数据、密码或密钥都可能被轻易泄露。

安全加密虚拟化（SEV） 将主内存加密功能与现有的 AMD-V 虚拟化架构集成在一起，以支持加密虚拟机。加密虚拟机不仅可以帮助它们免受物理威胁，还可以防止来自其他虚拟机甚至是来自虚拟机管理程序本身的威胁。因此，SEV 代表了一种新的虚拟化安全范式，特别适用于云计算，在这种环境下，虚拟机不需要完全信任其主机系统的虚拟机管理程序和管理员。与 SME 一样，支持 SEV 也不需要修改应用软件。

本文档提供了 SME 和 SEV 的技术概述，并描述了操作系统（OS）、虚拟机管理程序（HV）和客户虚拟机（VM）软件在各种不同环境中如何利用这些技术来保护 DRAM 中的数据。

SME 技术概述

主内存加密是通过片上内存控制器中的专用硬件执行的。每个控制器都包含一个高性能的高级加密标准（AES）引擎，当数据写入 DRAM 时对其进行加密，读取时解密，如图 1 所示：内存加密行为。数据的加密使用 128 位密钥，以一种利用额外物理地址调整的模式进行，以防止密文块移动攻击。

AES 引擎在 SME 中使用的加密密钥在每次系统重置时随机生成，对运行在 CPU 核心上的任何软件都是不可见的。该密钥完全由 AMD 安全处理器（AMD-SP）管理，这是一款作为集成在 AMD SOC 内的专用安全子系统的 32 位微控制器（ARM® Cortex®-A5）。密钥使用板载符合 NIST SP 800-90 标准的硬件随机数生成器生成，并存储在专用硬件寄存器中，在 SOC 外部从未以明文形式暴露。与后面描述的 SEV 模式不同，SME 不需要在 CPU 核心上运行的软件参与密钥管理。

内存加密的控制通过操作系统（OS）或虚拟机管理程序（HV）在软件管理的页表中进行。启用内存加密后，物理地址的第 47 位（也称为 C 位，表示加密）用于标记内存页是否受保护。OS或HV在页表项（PTE）中将物理地址的第 47 位设置为 1，以指示应加密该页，导致对该内存的访问会自动由内存控制器中的 AES 引擎进行加密和解密。

访问DRAM时，通过 AES 引擎对内存进行加密和解密确实会增加一定量的额外延迟。这种延迟对软件的影响在很大程度上取决于系统工作负载，但据估计，对系统性能的整体影响非常小。如果只加密了内存的子集，那么性能影响将会较小，因为未加密的访问通常不会产生额外延迟。

SME 使用模型

本节讨论了软件可以利用 SME 功能的两种不同示例模型。在第一个模型中，所有的 DRAM 都被加密，而在第二个模型中，只有选择的区域（对应于客户虚拟机）被加密。

全内存加密全内存加密对于许多计算系统来说是一个简单但令人信服的模型，特别是当系统的物理攻击受到关注时，包括政府数据中心和/或较小或偏远的企业数据中心，具有更有限的物理安全性。在全内存加密的情况下，所有DRAM内容都使用随机密钥进行加密，该密钥对冷启动、DRAM接口窥探和类似类型的攻击提供了强大的保护。对于使用NVDIMM的系统，全内存加密还提供了对攻击者移除内存模块并试图提取其内容的保护。

支持SME的全内存加密是通过OS或HV在所有页表的所有DRAM物理地址中设置C位来实现的。这应该既包括指令页和数据页，也包括与页表对应的页面本身。本质上，操作系统或HV软件可能将系统视为具有从地址0x8000 0000 0000开始的DRAM。在HV设置C位加密所有物理内存的情况下，所有由HV控制的虚拟机都与HV一起加密，并使用相同的加密密钥。

注意，支持通过SME加密的DMA到内存。从设备的角度来看，加密的内存访问只是一个正常的47位内存访问。

部分内存加密

页表中C位的使用为OS或HV提供了灵活性，可以根据需要选择只加密内存的一个子集。这样做仍然提供了加密内存的物理保护，也可以提高非敏感数据上的性能。此外，加密与未加密内存的选择可用于为关键工作负载提供一层隔离。

这种隔离的一个例子是只将客户虚拟机使用的内存标记为加密的系统。这可以在不对客户VM进行任何修改的情况下完成。通过在DRAM (如图3所示:加密虚拟机)对应的所有嵌套页表项中设置C位，hypervisor仅对VM内存进行加密。

这样的场景可以用来保护VM免受恶意机器管理员的攻击。虽然管理员可以访问硬件和主机系统，但即使使用内存扫描工具，他们也无法检查客户VM数据。

SME特殊考虑

SME为软件加密部分或全部内存页提供了一种直观的方法。然而，在使用加密内存时，有一些重要的特殊编程考虑必须考虑到。

首要考虑的是，硬件并不管理同一页面中加密和未加密副本之间的一致性。因此，软件在修改页面的C位时必须小心谨慎，确保如果需要修改页面的C位，则必须在修改页表之前从CPU缓存中刷新该页 。

值得注意的是，允许设备向加密内存发出DMA，但与CPU访问一样，它们必须设置物理地址的47位，这在一些32位的旧设备上是不可能的。为了补偿，软件可以利用IOMMU将设备请求地址重新映射为C位集合地址。

有关SME特性的其他技术细节可参见AMD程序员手册( APM )第2卷的最新版本

Transparent SME

虽然SME为管理主存加密提供了很大的灵活性，但它确实需要OS / HV的支持。透明SME ( TSME )是希望SME的物理保护与OS / HV解耦的系统选项。在TSME中，所有内存都是加密的，而不管特定页面上的C位值如何。该模式提供了一种无需软件修改即可启用加密的简单方法。

在支持的平台上，可以通过BIOS设置启用TSME。

Sev简介：复杂与融合

随着硬件和软件的进步，如今的计算系统比以往更加复杂。软件的规模和功能急剧增加，尤其是系统中负责安全的最具权限的内核级软件。例如，Linux内核已经从不足200k行的代码发展到如今的近2200万行。

这种演变也导致了比以往任何时候都更多的整合，允许系统在相同的硬件上执行更多的任务和做更多的工作。这种整合已经导致了许多积极的结果，如云、虚拟数据中心，任何人都可以在其上购买负担得起的计算时间。

然而，复杂与融合都会对系统的安全性产生普遍的负面影响。复杂的软件更难验证，更有可能存在黑客可以利用的漏洞。一个典型的Linux系统将近5.5 MB的内核代码加载到内存中，内存必须是无bug的，以避免破坏系统。

整合系统还会通过增加攻击面，允许许多不同的软件使用相同的硬件和共享资源(如内存)，从而对安全性产生负面影响。这种组合产生了一个依赖于大量特权无bug代码的安全模型，再加上庞大的攻击面为入侵提供了更大的可能性。

为了对抗这些力量，**安全加密虚拟化( Secure Encrypted Virtualization )**是AMD架构中加入的新特性，旨在更好地应对现代系统的复杂性和隔离性需求。SEV通过使用密码学、加密代码和数据来增强隔离性，并实现了一个全新的安全模型，其中的代码可以从高级特权代码(如虚拟机管理程序)中得到密码学保护。

SEV Security Model

传统的计算系统采用基于环的安全模型运行。在该模型中，高特权代码可以完全访问其所在层级和所有低特权层级的资源。

在SEV模型中，在不同级别(即管理者vs客人)上执行的代码是孤立的，因此不能访问对方的资源。尽管管理程序级别传统上比客户级别"更有特权"，但SEV通过密码隔离将这些级别分离。这为低特权代码提供了额外的安全性，而不需要低特权代码启动和执行所依赖的高特权代码的信任。管理程序和客户机之间的通信仍然是可能的，但是这些通信路径是严格控制的。

因此，SEV技术威胁模型的基础，假设攻击者不仅可以在目标机器上执行用户级别的特权代码，而且可能在更高权限的虚拟机管理程序级别执行恶意软件。攻击者也可能拥有对机器的物理访问权限，包括对DRAM芯片本身的访问权限。在所有这些情况下，SEV提供额外的保证来帮助保护客户虚拟机代码和数据免受攻击者的攻击。注意，SEV并不能抵御针对来宾的拒绝服务攻击。

SEV Use Cases

SEV围绕硬件虚拟机的概念构建，可以在多种用例中用于增强安全性。由于使用了主存加密，SEV提供了与前面描述的SME相同的物理攻击防护安全收益。除此之外，SEV还可以用于保护以下环境。

Cloud

云，特别是基础设施即服务( IaaS )数据中心的增长使得计算能力变得便宜。然而，这种增长有安全挑战，因为云基础设施/人员可能并不总是值得信赖的。在处理敏感数据时尤其如此，例如健康记录或商业秘密。此外，在多个客户之间共享硬件引起许多类型的工作负载所有者的安全担忧。尽管软件设计者付出了努力，但已经出现了许多这种隔离失败的案例，导致敏感代码或数据的泄露。

根植于硬件本身的SEV可以通过提供更好的安全隔离来提高这些IaaS云中的安全水平。虽然现有的安全技术如微软的BitLocker装置加密®和LUKS可以保护硬盘中的静态数据，但SEV保护使用中的数据，使客户工作负载能够相互加密保护，并保护主机软件。云数据中心中具有恶意意图的管理员将无法访问托管VM中的数据。

沙箱

SEV是围绕一个安全沙箱环境的想法构建的，其中软件可以执行并被保护。这些沙箱可以像一个完整的VM一样大，有自己的磁盘和操作系统，也可以很小，用于更细粒度的隔离。例如，SEV硬件可用于将Docker容器与主机系统进行加密隔离，以更好地保护机密数据。

SEV体系结构

技术概况

SEV是对AMD - V架构的扩展，支持在hypervisor的控制下运行多个虚拟机。当启用时，SEV硬件使用VM ASID标记所有代码和数据，该标记指示数据来自或打算用于哪个VM。该标签在SOC内部的任何时候都保存着数据，并防止数据被所有者以外的任何人使用。

标签保护SOC内部的VM数据，AES采用128位加密保护SOC外部的数据。当数据离开或进入SOC时，通过硬件基于关联标签的密钥分别对其进行加密/解密。

每个VM以及hypervisor都与一个标签相关联，从而产生一个相关联的加密密钥。由于标签和内存加密，数据仅限于使用该标签的VM。如果数据被任何人访问，包括管理程序，他们将只能看到数据的加密形式。这提供了虚拟机之间以及虚拟机与hypervisor之间的强加密隔离。

内存加密

SEV使用与前面描述的SME特征相同的高性能内存加密引擎。它还在页表中使用相同的C位来标记加密的页面，尽管有一些额外的限制。

SEV的关键特征之一是客户虚拟机能够选择他们希望私有的数据内存页 。这种选择是使用标准的CPU页表完成的，并且完全由客户控制。私有内存使用客户特定密钥加密，而共享内存可能使用管理程序密钥加密。该功能允许VMs标记其想要保留的内存数据的选定页面，以及其他用于与其他VMs或管理程序通信的内存数据。在典型的安排中，访客会将其所有代码和数据映射为私有的，除了它选择公开的特定共享页面。出于安全考虑，SEV硬件确实需要某些类型的内存(包括指令页和页表)始终是私有的，以保护虚拟机。

示例通信配置如图10所示。在本例中，启用SEV的来宾和管理程序通过内存进行通信，两个实体都标记为共享。其他所有访客内存均使用访客密钥( HV无法使用)进行加密。HV不用于直接访客通信的任何内存都使用前面描述的SME特征进行加密。

密钥管理

SEV的安全性高度依赖于内存加密密钥的安全性。暴露于恶意实体，如恶意的或错误的hypervisor，会危及SEV保护的客户。虽然hypervisor必须管理客户及其资源，但是hypervisor本身绝不能获取内存加密密钥的知识。运行在AMD - SP内部的SEV固件提供了一个安全的密钥管理接口来实现这一点。hypervisor使用该接口为安全客户机启用SEV，并执行常见的hypervisor活动，如启动、运行、快照、迁移和调试客户机。

为了保护启用了SEV的访客，固件辅助执行了三个主要的安全属性：平台的真实性、已启动访客的认证和访客数据的机密性。

对平台进行认证可以防止恶意软件或流氓设备伪装成合法平台。平台的真实性由其身份密钥来证明。该密钥由AMD签署，以证明该平台是具有SEV功能的真实AMD平台。它还由平台的所有者签署，以显示谁管理和拥有机器给客户的所有者或远程平台上的其他固件实例。

客户启动证明向客户机所有者证明他们的客户机在启用SEV的情况下安全启动。固件向客户所有者提供与SEV相关的客户机状态的各种组件的签名- -包括内存的初始内容- -以验证客户机处于预期状态。通过该证明，客户机所有者可以确保管理程序在向客户机传输机密信息之前不干扰SEV的初始化。

这个过程的一个例子如图12所示。最初，客户所有者向云系统提供客户镜像。SEV固件协助启动客户机，并提供测量回传给所有者。如果客户机所有者认为这种测量是正确的，那么他们反过来向运行中的客户机提供额外的秘密(如磁盘解密密钥)，使其能够继续启动。

客户机的机密性是通过使用只有SEV固件知道的内存加密密钥对内存进行加密来完成的。SEV管理接口不允许内存加密密钥- -或任何其他秘密SEV状态- -在固件外部导出，而不对接收者进行适当的认证。这使得管理程序无法访问密钥，从而无法访问客户的数据。

该接口还提供了将客户数据迁移到另一个SEV能力平台的机制。在此操作中，客户机的存储内容在传输过程中保持加密。一旦远程平台被认证，SEV固件会安全地发送客户的内存加密密钥，以便远程平台可以自行运行客户。这种传输机制允许hypervisor在启用SEV的情况下安全地实现迁移和快照功能。

SEV Software Implications

Hypervisor

与传统虚拟化一样，SEV仍然依赖于Hypervisor来实现许多虚拟机功能，如设备模拟和调度，但减少了对Hypervisor安全性的依赖。启用SEV的客户机仍然可以根据需要使用Hypervisor，但是当内存页不打算在VM外部共享时，可以通过将其标记为私有来保护自己。

运行时Hypervisor与AMD - SP进行通信，以协调内存加密密钥的管理。这种通信是通过AMD - SP驱动程序完成的，涉及到在VM即将运行时通知AMD - SP等任务，从而允许AMD - SP将适当的加密密钥加载到AES - 128加密引擎中。Hypervisor还与AMD - SP通信，建立安全机制执行客户认证、执行迁移等。

虽然Hypervisor可以控制用于运行VM和选择加密密钥的ASID，但这并不被认为是一个安全问题，因为加载的加密密钥是没有意义的，除非客户已经使用该密钥加密。如果加载了错误的密钥或者对客户机使用了错误的ASID，那么客户机的第一个指令获取将失败，内存将被错误的密钥解密，导致垃圾数据被执行(并且极有可能造成故障)。

Guest

支持SEV的客户机中的操作系统必须意识到这一新的硬件特性并适当地配置其页表。这可以用类似于SME全内存加密模式的方法来完成，其中大多数DRAM地址被配置为C位(位47 )设置为1。

对于支持SEV的客户来说，一个重要的考虑因素是SEV硬件出于安全原因不允许DMA进入客户加密内存。所有的DMA，无论是来自真实硬件还是HV仿真设备，都必须发生在共享访客内存中。因此，客户操作系统可以选择将内存页分配给DMA作为共享的( C位清除)，或者将数据复制到/从特殊的缓冲区(又名"弹跳缓冲器")进行DMA。一些操作系统已有对弹跳缓冲区的支持，可用于此目的，如swiotlb Linux功能。

最后，值得注意的是，SEV支持多核客户机，并且数据可以在这些核心之间共享，不会带来额外的性能损失。Hypervisor必须对特定客户的所有虚拟CPU实例使用相同的ASID。

SEV特殊考虑

前面列出的许多关于SME功能的特殊考虑也适用于SEV。特别地，与SME一样，在使用不同的C - bit访问页面之前，页面必须从缓存中刷新。此外，在更换硬件内存加密密钥之前，Hypervisor软件必须执行完整的缓存刷新，以确保使用该密钥的任何修改数据都已写回DRAM。

最后，由于在64位或32位PAE模式下运行时，C位仅由客户操作系统控制，因此在所有其他模式下，SEV硬件迫使C位为1。这允许客户操作系统立即开始运行加密代码，然后安全地过渡到其最终模式。

总结

本文中提出的两个内存加密特性代表了在各种环境中可能使用的通用计算机安全的主要步骤。

安全内存加密技术是一种灵活而强大的体系结构特性，它允许对操作系统或管理程序的主存进行加密。本文阐述了内存加密的几种具体使用模型，包括全内存加密、选择性加密和透明加密。所有模型都提供了针对物理硬件攻击的新保护，并且在某些情况下可以用来帮助保护系统免受流氓管理员的攻击。其他的使用模型也是可能的，可以提供额外的选择和性能/安全权衡。SME不需要对应用软件进行任何修改，只要对操作系统或管理程序进行适当的修改，系统中的所有应用都可以得到保护。

此外，可通过安全加密虚拟化增强VM安全性，支持运行管理程序无法直接访问的加密客户。这不仅为云用户提供了新的保护，也为希望限制其对客户数据可见性的云主机提供了新的保护。基于AMD - V技术，SEV可同时用于云端和Docker类型的模型，为虚拟化环境提供了一种新的安全模型。与SME技术一样，不需要对客户机进行应用软件更改，通过专用硬件引擎快速透明地执行VM加密。