1 、前言

   在当前的计算环境中，应用程序依赖系统软件来提供服务，例如对计算系统资源的访问管理。在这里系统软件包括操作系统（ OS ），大多数情况下也包括管理程序。传统上，必须信任系统软件，因为它可以完全控制应用程序及其数据。操作系统或管理程序可以访问或修改任何应用程序的数据，或潜在地篡改应用程序实现的任何安全功能而不会被检测到。因此，底层软件必须是可信计算库 (TCB ： Trusted Computing Base) 的一部分。在共享环境中，客户被迫相信开发、配置、部署和控制系统软件的实体没有恶意。客户还必须相信系统软件不会受到提升权限和损害客户应用程序机密性和完整性的攻击。这种广泛的信任要求通常难以证明其合理性并带来重大风险，尤其是对于采用公共云服务的客户而言。本文介绍了 Power 服务器为解决此类问题而采用的一种新方法。

   为解决对安全敏感的应用程序的这些问题，针对不同的平台都有对应的技术，例如 IBM 的 SecureBlue++ 、 Intel 的 SGX 和 AMD 的安全加密虚拟化（ Secure Encrypted Virtualization ） 。目前 K1 Power 全面支持安全虚拟机 (SVM) 技术，通过 Power 的保护执行机制（ Protected Execution Facility ）使得 SVM 无论处在空闲还是运行状态时，都可以保护 SVM 免受其他软件的影响。 为了支持这些功能， K1 Power 采用了一种称为 Ultravisor 的新模式，如图 1 中的红框所示，它具有比 hypervisor 模式更高的权限。

   如图 1 所示，当用户从最高权限的 Ultravisor 模式转移到最低权限的 Problem 模式时，权限会降低。

2 、 SVM 简介

   SVM 由客户在支持保护执行机制的系统上创建并运行，每个支持保护执行机制的系统都有一个公钥 / 私钥对，其中的私钥只有系统知道（它不会暴露给系统的所有者）， SVM 的创建者为每个被授权运行 SVM 的系统提供公钥。在 Power 系统制造过程中，厂家会在每个系统上生成唯一的系统标识密钥对，并将相应的公钥交付给所有者。交付后，系统所有者可以使用厂家提供的工具更改他们的密钥对。使用可信平台模块 (TPM) 的功能，系统所有者可以选择为每个系统使用不同的密钥或为一组系统使用相同的密钥。需要注意的是，在这个过程中厂家不参与授权 SVM 。

如果需要创建 SVM ，客户必须完成以下步骤：

Ø 创建一个将成为 SVM 的 虚拟机（ VM ）。

Ø 从系统所有者处获取授权运行 SVM 的每个系统的公钥。

Ø 利用厂家提供的工具从 VM 构建 SVM 。

Ø 将 SVM 分发到要运行 SVM 的一个或多个系统。

   SVM 创建之后，无论处于空闲还是运行状态都会对敏感信息、例如密钥等，进行加密保护。

   图 2 显示了保护执行机制的工作机制。图片底部代表硬件环境，中间部分代表固件 / 软件环境，顶部代表应用环境。 保护执行机制建立在安全和可信的引导之上。每个系统都有一个公钥 / 私钥对，其中私钥受 TPM 保护，只有在启动了正确、经过验证的固件后才可用。该图的右下方显示内存被划分为安全内存和普通内存。作为安全启动过程的一部分，受保护的执行 Ultravisor （或 Ultravisor ）被加载到安全内存中。在这个固件控制了系统之后，它将控制权交给操作系统，通常是一个开始运行的管理程序。如图顶部所示，目标系统的公钥用于在创建安全 VM 时包装其加密密钥。当 SVM 启动时， SVM 中的软件会调用 Ultravisor ， Ultravisor 会将 SVM 移动到安全内存，并在其中恢复执行。普通虚拟机可以在相同的硬件上运行，但没有任何额外的保护。

   SVM 使用 hypervisor 调用（ h-calls ）从底层 hypervisor 获取服务。 我们的模型引入了一种称为 Ultravisor 模式的新模式，其中包含相关的固件和 Ultravisor 调用 (u-calls) 。 这个固件，我们称之为 Ultravisor ，将开源以提供更高的透明度，并允许社区审查和加强其安全性。 Ultravisor 过滤 SVM 和 hypervisor 之间的所有调用，以确保仅将执行调用所需的信息传递给 hypervisor 。 它还确保只有来自 hypervisor 的响应返回到 SVM 。 硬件防止未经授权的系统软件（和硬件），例如 hypervisor 和普通虚拟机，引用安全内存。 同时 hypervisor 保留了其所有传统功能。

   需要注意的是，对于空闲 SVM 的部分保护是通过磁盘加密保护功能实现的，例如 Linux dm-crypt 。 这引出了以下一些问题：

Ø 在 hypervisor 保持其正常功能但无法引用安全内存的情况下，如何启动 SVM ？

Ø 换页空间是如何工作的？ 它是否允许 hypervisor 访问 SVM 内存？

Ø I/O 是如何工作的？

Ø 这是一个重大的变化； 它将如何影响正常的虚拟机？

Ø 对性能有什么影响？

Ø 受保护的 SVM 磁盘映像究竟是什么样的？

我们将在本文的其余部分解释如何解决这些问题。

3 、有关问题的解决

3.1 、启动 SVM

   因为 SVM 的格式类似于 zImage ，所以现有的引导加载程序应该能够在不修改的情况下加载它。当 hypervisor 启动 VM 时，它会将 VM （或 VM 的一部分）复制到内存中，并将控制权转移到 VM 中指示的入口点。 SVM 具有类似的格式，只是 SVM 的入口点位于受完整性保护且未加密的软件中。该软件必须做的一件事是从作为普通 VM 运行过渡到作为 SVM 运行。这是通过进行进入安全模式 (ESM) u-call 来完成的。为响应此调用，受保护的执行 Ultravisor ：

Ø 复制 SVM 以保护内存。

Ø 检查系统是否有权运行 SVM 。

Ø 验证明文没有被修改（如果系统被授权）。

Ø 解密（通过完整性检查）那些需要解密的部分。如果完整性检查通过，则在安全内存中继续执行。

   将 SVM 复制到安全内存后，将在安全内存中继续执行。安全内存的一个特点是它不能被管理程序寻址。

3.2 、换页空间

   如果需要使用换页空间， Ultravisor 会为 hypervisor 提供所请求的 SVM 内存页面的加密版本。 （我们的架构支持 SVM 的内存过度使用，尽管最初可能不支持过度使用。）用于保护 SVM 的加密模式是高级加密标准 (AES) 的扩展，称为 Integrity Aware Parallelizable Mode (IAPM) 。 IAPM 检测管理程序（或任何其他人）对 SVM 页面加密表示的任何修改。

3.3 、 I/O

   SVM 可以向 Ultravisor 指定其内存的特定页面将与 hypervisor 共享而不受保护。这会导致 SVM 的页表指向普通内存中的页。最初， SVM 中的所有 I/O 都将被限制为虚拟 I/O 。因为 hypervisor 只能引用已被 SVM 明确请求与其共享的页面，所以必须修改 VirtIO 以在 SVM 中工作。必须使用反弹缓冲区，因为 hypervisor 无法观察 SVM 内部的任何内容。 SVM 负责正确保护（加密）通过共享页面写入的任何数据。共享页面是必要的，这样 SVM 才能与其他实体通信，因为保护其内存的密钥在其运行的系统之外是未知的。如果 SVM 的创建者担心任何通信的安全性，则应使用传输层安全性 (TLS) 或类似机制来保护数据。对于通信协议， SVM 内部的 TLS 在将数据放入未受保护的内存之前对安全内存中的数据进行加密。

   当 SVM 的磁盘受到加密文件系统（例如 dm-crypt ）的保护时，必须在 VM 引导时内核可以使用密码，而无需控制台交互。 SVM 可能具有使用 dm-crypt （或类似功能）保护的其他磁盘，其中这些磁盘的密码在 SVM 内受到保护。

3.4 、专用于 VM 进行 I/O 的设备

o 性能影响

   对普通虚拟机的影响很小（基本上为零）。由于 hypervisor 和 Ultravisor 之间的接口是半虚拟化的，因此对 SVM 的影响最小化。以前由 hypervisor 控制的一些设施现在由 Ultravisor 控制。当 hypervisor 需要使用这些工具时，它的行为必须为 Ultravisor 所接受。

o 未受保护的 VM 磁盘

   SVM 可以使用不受 dm-crypt 或类似机制保护的磁盘。但是，除非数据在 SVM 中通过另一种机制加密，否则不会对写入该磁盘或从该磁盘读取的数据提供保护。

o 受保护的 SVM 磁盘映像

   如果 SVM 由 petitboot 加载，则 SVM 的内容将类似于图 3 中所示的内容。第一部分包含加载程序和所示的附加信息。加载程序执行 ESM u-call 。引导代码执行 ESM u-call 。只有当 SVM 被授权在当前系统上运行并且 Ultravisor 可验证的所有区域都已检查时，此调用才会返回到 SVM 。下一个区域指示在引导过程中将用于服务的共享内存量。随后是自我保护的 ESM blob ，它包含在目标系统的公钥下加密的对称密钥以及用于管理 SVM 的其他元数据。最后是引导文件系统和根文件系统。数字签名保护是指在运行之前，必须检查引导文件系统内核上的签名以及从 RAM 盘运行的所有文件的签名。如果任何签名检查失败，则引导失败。块层加密是指诸如 dm-crypt 之类的系统。

4 、总结

   在本文中简要介绍了在 Power 服务器上通过 SVM 为应用提供安全保护的机制。 由于 SVM 已加密，因此这些虚拟机在磁盘上或通过网络传输时受到保护（即使未使用加密传输）。 每个系统都配置有公钥 / 私钥对。 授权 SVM 运行的信息是在授权系统的公钥下加密的。 可以授权 SVM 在多个系统上运行。在加载 SVM 时，授权系统会验证它没有被篡改。 如果发现篡改将不会被执行。 SVM 使用 hypervisor 服务，但受到严格保护，不会将信息意外泄漏到 hypervisor 。