支持模拟虚拟 TPM¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/nova/+spec/add-emulated-virtual-tpm

有一类应用程序期望使用 TPM 设备来存储密钥。为了在虚拟机中运行这些应用程序，在访客虚拟机中暴露一个虚拟 TPM 设备将会很有用。因此，建议添加一个 placement trait，可以在 flavor 或 image 中请求，这将导致相关的 virt 驱动程序将此类设备添加到 VM 中。

问题描述¶

目前，nova 中创建虚拟机时，无法向客户机提供虚拟 TPM 设备。

用例¶

支持虚拟化现有应用程序和操作系统，这些应用程序和操作系统期望使用物理 TPM 设备。至少有一个 hypervisor (libvirt/qemu) 当前支持创建与主机上的每个 VM “swtpm” 进程关联的模拟 TPM 设备，但没有办法告诉 nova 启用它。

提议的变更¶

最近的 libvirt 和 qemu (以及可能其他 hypervisor) 支持模拟的 vTPM 设备。我们建议修改 nova 以利用此功能。

对于 libvirt virt 驱动程序，特别是 libvirt 4.5 之后就支持 vTPM。期望的 libvirt XML 参数如下

...
<devices>
  <tpm model='tpm-tis'>
    <backend type='emulator' version='2.0'>
    </backend>
  </tpm>
</devices>
...

支持模拟 TPM 至少需要 qemu 2.11，尽管作者推荐 qemu 2.12。virt 驱动程序代码应该添加合适的版本检查（对于 LibvirtDriver，这将包括对 libvirt 和 qemu 的检查）。目前模拟 TPM 仅支持 x86，但这是一种实现细节而不是架构限制。

支持模拟 TPM 还需要主机上可用 “swtpm” 二进制文件和库。如果无法通过 hypervisor 检查它是否可用，我们可能需要添加一个 hypervisor 特定的 nova.conf 标志，指示我们希望启用模拟 TPM 支持。这预计默认情况下为 false，以尽量减少升级时的意外情况。

为了请求此功能（并允许调度到提供此功能的节点），我们建议定义两个新的 traits，COMPUTE_SECURITY_TPM_1_2 和 COMPUTE_SECURITY_TPM_2_0。（模拟 TPM 只是主机上运行的一个进程，因此库存的概念不适用。）这两个 traits 代表当前支持的 TPM 规范的两个不同版本。（有关这两个版本之间差异的摘要目前可在此处找到。）flavor extra-specs 或 image 属性可以指定类似 trait:COMPUTE_SECURITY_TPM_1_2=required 的内容，以指示他们希望访问 TPM。能够为其实例提供 TPM 的 virt 驱动程序将负责在计算节点上设置这两个 traits 中的一个（或两个）。如果实例在 flavor 或 image 中指定了其中一个 trait，virt 驱动程序将执行必要的操作以向实例提供 TPM。如果由于任何原因这不可能，则实例创建将失败。

在使用 COMPUTE_SECURITY_TPM_2_0 时，模拟 TPM 设备有两种可能的设备模型，TIS 和 CRB。默认情况下将使用 TIS 模型，但也可以通过在 image 中设置 hw:tpm_model=TIS 或在 image 属性中设置 hw_tpm_model=TIS 来显式指定。可以通过在 flavor 中设置 hw:tpm_model=CRB（或通过等效的 image 属性）来指定 CRB 选项。对于 libvirt/qemu，支持 TPM 2.0 的 libvirt 版本 (v4.5.0) 也支持 CRB 设备模型。

如果 flavor 和 image 都指定了 TPM trait 或设备模型，并且这两个值不匹配，将引发异常。如果将 COMPUTE_SECURITY_TPM_1_2 与 CRB 模型一起指定，hypervisor 将无法创建实例。

作为超出当前工作范围的未来增强功能，可以将其扩展为支持物理 TPM 直通。在这种情况下，virt 驱动程序还将通告一个资源类为 PTPM 且 total=1（因为当前硬件只有单个 TPM）的库存，并且 image 或 flavor 可以通过指定 resources:PTPM=1 来请求它。在这种情况下，不需要 trait，因为实例对 TPM 的需求由资源请求隐含。此外，对于 TPM 直通，设备模型由实际硬件设备控制。

作为实现此功能的一部分，nova 冷迁移代码需要复制包含模拟 TPM 文件的目录。对于 libvirt，这意味着从 LibvirtDriver.migrate_disk_and_power_off() 中复制 /var/lib/libvirt/swtpm/<instance> 下的文件。

可以通过在 shelve 操作期间将持久 TPM 数据保存为 glance image，并在 unshelve 操作期间重新创建它（并删除 image）来支持 shelve/unshelve。

调整大小将导致重新调度，因此不应该有问题。如果管理员从带有 TPM 的 flavor 调整大小到没有 TPM 的 flavor，nova 不会关心，但它可能会在访客虚拟机中引起问题。

重建到新 image 是一个问题，如果新 image 指定了 TPM trait 并且当前主机无法提供 TPM 支持。这将导致重建失败。在这种情况下，用户需要使用合适的 image 进行重建。

应该注意的是，如果计算节点发生故障并且 VM 必须在另一个计算节点上重建，我们将丢失任何模拟 TPM 数据。在共享存储的情况下，这与将硬盘从一台物理机器中取出并放入另一台物理机器中完全相同。

备选方案¶

与其使用 trait，我们可以使用具有大型库存的资源。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

访客虚拟机将能够使用模拟 TPM 来实现物理 TPM 提供的所有安全增强功能，以保护自身免受来自访客虚拟机内部的攻击。访客虚拟机仍然必须信任主机。

通知影响¶

无

其他最终用户影响¶

目前没有计划使模拟 TPM 适用于 shelve/unshelve。要可靠地实现这一点，需要在“shelve”时将持久 TPM 数据文件保存到 glance image 或 swift 对象，然后在“unshelve”时恢复数据（并删除 image）。

使用 UEFI NVRAM 的实例目前处于类似的位置，因为 NVRAM 在 shelve/unshelve 期间不会持久化。

性能影响¶

可以忽略不计。

其他部署者影响¶

无

开发人员影响¶

各个 virt 驱动程序将能够根据需要实现模拟 vTPM。

升级影响¶

如果需要 config 选项来选择加入模拟 TPM 支持，则操作员需要在升级后适当地设置 config 选项。

实现¶

负责人¶

主要负责人: cfriesen
其他贡献者: 无

工作项¶

支持新的 placement traits
Libvirt 驱动程序更改以向 placement 报告 traits
Libvirt 驱动程序更改以启用指定 libvirt XML
Libvirt 驱动程序更改以在冷迁移时复制 vTPM 文件。

依赖项¶

最新的 qemu/libvirt
“swtpm” 二进制文件和库

测试¶

将添加单元和功能测试。

文档影响¶

操作指南和最终用户指南将相应更新。功能支持矩阵将更新。

参考资料¶

Qemu 关于 tpm 的文档：https://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt
请求模拟 TPM 设备的 Libvirt XML：https://libvirt.org/formatdomain.html#elementsTpm

历史¶

修订版¶
发布名称	描述
Stein	引入
Train	重新提出

添加对模拟虚拟 TPM 的支持