SEV-TIO

AMD CPU 从 Venice 开始支持。

TDX Connect

Intel CPU 从 GNR 开始支持。

复习一下没有 TDXIO 的情况，MMIO 是如何被模拟的？

为什么要把 MMIO 替换成 TDCALL？通过 EPT Misconfiguration，可以让 KVM 迅速知道这是一个 MMIO 请求，然后对 guest 的 IO 动作进行模拟。但是在 TDX 中这样不行，因为 EPT Misconfiguration VMEXIT will expose the register state to the host. 所以 MMIO 模拟是需要通过 guest 直接 call 到 TDX Module，让 TDX Module 来做处理，TDX Module 在将必要的信息 exit 到 KVM 来让 KVM 来处理。In TDX, MMIO regions typically trigger a #VE exception in the guest. The guest #VE handler then emulates the MMIO instruction inside the guest and converts it into a controlled TDCALL to the host, rather than exposing guest state to the host.

kernel.org/doc/Documentation/x86/tdx.rst Please see MMIO handling.

TDX (without TDXIO) 使用 VirtIO 的情况下，guest 和 KVM 其实是 share 同一片地址（不只是那几个 ring 占的 page，更多的是每一个 ring 里面每一个 entry 指向的内存），也就是是 TD shared memory。需要有一次拷贝：it is the responsibility of the TD to copy data from the shared memory used by devices to TD's private memory used by workloads running inside the TD and vice versa, 比如说应用内存是 private 的，应用想要读取磁盘，那么 TD 就需要从 virtio 的 share memory 拷贝到应用自己的内存地址中，多了一次拷贝。

没有 TDX 使用 virtio 的时候，ring 里每一个 entry 指向的内存可以直接 map 给应用使用，不需要多余的拷贝。

Without TDXIO:

  • 原来的 guest driver 就是 VirtIO case：直接改造 guest driver，把 MMIO 替换成 TDCALL: replace MMIO with TDCALL(TDG.VP.VMCALL)，之所以要替换请看上面原因。
  • 原生 driver case，全虚拟化，没有使用 VirtIO：#VE handler handle MMIO access, then call TDCALL.
  • 如果是设备直通: 需要引入一个 shared memory 作为 bounce buffer. DMA remapping to shared memory rather than private memory in TD, then TD copy the data in shared memory to private memory. 引入 bounce buffer 是因为 private page 里的内容都是加密的，如果直接 DMA 到 Device，Device 压根没法用。TDX 在写入 shared page 的时候，上面的内容是 AES 引擎加密过的吗？肯定不是，是直接明文写入的，如果还是加密写入，那么 VMM 访问的时候应该对应硬件也会解密，用什么 key 来解密呢，这部分是没有办法做的？所以一般来说，为了隐私性以及出于数据保护的需求，厂商这一步一般使用软件加解密的方式先软件加密完后再放到 shared buffer，然后 DMA 到设备比如说 GPU 后，GPU 侧也运行一些软件来进行解密（没有 GPU TEE 的方案）。有了 GPU TEE 方案之后，可以直接硬件加解密，不需要软件介入，根据 Nvidia 数据，性能接近没有损失。

With TDXIO:

  • Direct access to private memory. 将设备纳入 TCB。也就是说设备变成了可信的设备，guest 选择相信设备了，设备不需要做修改，guest 相信设备，硬件也就应该支持设备通过 DMA 读/写内存。这难道是通过给 vt-d 页表里也加上几位 key 来实现的？这样 DMA 发生时，平台上某个组件可以先解密内存数据，然后传给设备，或者另一个方向，设备 DMA 到内存时，直接加密设备。但是这种情况设备上的数据时明文的（毕竟在 TCB 之内），所以仍然有数据泄露的风险。

MKTME 和 TDX 并不是绑定的，legacy VMX VM，可以只开启 MKTME，此时 VMM 被包含在 TCB 里面，默认是可信的。可以用来增加内存机密性和内存完整性。VT-d 的页表和 EPT 页表一样，都是把 GPA -> HPA 翻译，因此页表项 HPA 的一部分 bit 需要对应相同的 keyID。这样，因为 HPA 最后指定了 keyID，所以硬件会在写入时根据 keyID 加密，读取时根据 keyID 解密。对于其他 VM 或者 VMM 进程，因为其页表 HPA 中没有 keyID，因此没有办法进行加解密。

基于 6 种组合，有三种 IO 模式：

  普通 GPU 部分支持机密计算的 GPU 如 Hopper 完整机密计算能力的 GPU 如 Blackwell
TDX (without Connect) 第一种 第二种 第二种
TDX Connect 第一种 第二种 第三种

第一种模式：TD 通过不加密的 Bounce buffer 与设备通信

包含两种情况：

  • TD (without Connect) + 普通 GPU（无任何机密计算能力）
  • TD Connect + 普通 GPU（无任何机密计算能力）

因为对非 TEE 设备，TD 是不信任的，GPU 没有在 TCB 里面，因此拷贝到 bounce buffer (shared memory) 里的数据其实都是没有保密需求的（因为 GPU 端是普通 GPU，没有做解密的能力），也就是都是通过 CPU 拷贝过去的明文，因此设备是可以直接进行 DMA 的（且不需要解密）。这一部分的主要开销为 copy 的开销，没有加密解密的开销。

第二种模式：TD 通过加密的 Bounce buffer 与设备通信

其实这包含了几种情况：

  • TD (without Connect) + TEE 不完整支持的设备比如 Hopper 架构；
  • TD Connect + TEE 不完整支持的设备比如 Hopper 架构；
  • TD (without Connect) + TEE 完整支持的比如说 Blackwell 架构。

设备被纳入了 TCB 里面，因为我们要先加密再通信了。

下面两段说明 shared memory 也是需要软件加密之后才放上去的，然后解密是在设备端做的，同样，设备在做 DMA 到 shared memory 前也需要先加密，因为要 properly protect its secret data。

[!PDF|annotate] [[TDX Connect.pdf#page=10&selection=27,0,29,74&color=annotate|TDX Connect, p.10]] For some IO use cases, such as networking and storage, TD may employ software based cryptographic techniques for data protection, however this approach suffers from performance overhead.

[!PDF|annotate] [[TDX Connect.pdf#page=10&selection=32,21,36,24&color=annotate|TDX Connect, p.10]] Besides the performance overhead, the cryptographic data protection does not allow the TD to offload computation to legacy GPU or FPGA accelerators and requires them to be in the TCB of the TD and properly protect its secret data.

Bounce buffer 里其实就是密文。只不过是软件加密：

  • 如果是 IO 写操作，NV 驱动软件做加密，GPU TEE 硬件做解密；
  • 如果是 IO 读操作，则是 GPU TEE 硬件做加密，NV 驱动软件做解密。

由 NV 驱动软件和 GPU 设备进行 SPDM 密钥的协商。

这一部分的开销就有两部分了：

  • copy 到 bounce buffer 的开销；
  • NV 驱动加密的开销。

第三种模式：TD 不需要 bounce buffer 与设备直接加密通信

之前密钥协商是通过 NV 驱动和 GPU 的加解密引擎使用 SPDM 协议（PCIe 协议）来协商的，现在 IOMMU 里支持了硬件协商密钥，并且每次传输硬件侧自动加密解密，这样省去了 bounce buffer 以及软件加解密，更加方便。

宏观来说，这说明其实是 CPU TEE 选择了 trust GPU TEE。

包含了这种情况：

  • TDX Connect + TEE 完整支持的比如说 Blackwell 架构。

PCIe 传输中的加密：Intel TDX Connect TCB does not include switches and bridges, therefore it is required by the host VMM to setup selective IDE stream to guarantee end-to-end IDE protection between TD-VM running on the host CPU, and the TDI running on the TEE-IO device.

流程如下：

  • 如果 GPU 需要通过 DMA 读 CPU 侧内存中的数据，那么数据是这么流动的：内存中的实际数值 -> 明文（MKTME 解密）-> 密文（CPU 侧 SPDM 加密）-> 明文（GPU 侧 SPDM 解密）；
  • 如果 GPU 需要通过 DMA 写 CPU 侧内存中的数据，那么数据是这么流动的：GPU 中的明文 -> 密文（GPU 侧 SPDM 加密）-> 明文（CPU 侧 SPDM 解密）-> 密文落盘（CPU 侧 MKTME 加密）；

CPU 侧虽然会出现一次明文，但是因为这是 CPU 侧硬件自动完成加解密的，所以不存在泄漏的风险（应该不会借助内存做加解密）。

先用 SPDM 进行身份认证和密钥交换，随后数据使用 Select IDE 进行传输。

小问题：SPDM 密钥协商和 MKTME 使用的是同一个吗？如果是的话，那么就不需要内存总线先解密然后硬件加解密引擎再加密了吧？不是同一个，而是新协商的密钥，因此解密再加密操作是必须的。之所以不是同一把，主要原因是 MKTME 里的密钥和 SPDM 协商的密钥用途不同，且 2 者在设计上也不是一个维度和领域的事情。前者属于每个 CPU 内部的微架构设计，比如 AMD/海光、ARM、Intel 在设计自己的类似 MKTME 的硬件上都属于 CPU 内部设计，不是通用的和标准化设计，而 SPDM 协议是 DMTF 国际标准组织设计的，因此二者处在不同的设计域，没法统一。如果能统一，性能会进一步提升，但这就属于 CPU 私有设计了，未来至少两代之后的 CPU 可能会为了追求极致性能会出现同一把 key 的情况，但至少 GNR 和下一代应该还是设计成 2 把不同的 key。

像 TDX 一样，GPU TEE 也有自己的版本的，不是所有 GPU TEE 版本都能支持上面这种只靠硬件 SPDM 协议协商密钥的场景，还是需要 GPU 做适配才能从 NV 软件驱动加密过渡到直接硬件协商密钥，上述所有分析在 NVIDIA Confidential Computing 可以印证：

NVIDIA was the first GPU to deliver Confidential Computing on the NVIDIA Hopper™ architecture with the unprecedented acceleration of NVIDIA Tensor Core GPUs. NVIDIA Blackwell architecture has taken Confidential Computing to the next level with nearly identical performance compared to unencrypted modes for large language models (LLMs)

因为 Hopper 是 GPU TEE 的早期版本，所以不支持硬件方式，只支持软件方式，因此其性能较低（即使有 TDX Connect 的能力）；但是 Blackwell 升级了 TEE 能力，支持了 SPDM 硬件协商，因此能够充分利用 TDX Connect 的能力，从而达到无损的性能。

TDX / GPU TEE 的性能比较

  • CPU TEE + GPU TEE w/ Trusted I/O > CPU TEE + 普通 GPU（bounce buffer 是明文） > CPU TEE + GPU TEE w/o Trusted I/O
  • GPU 负载较高的话，三者性能差距会被大幅度缩小；
  • GPU 负载较低的话，后两者与前者的性能差距明显。

TEE-IO device interface (TDI)

其实就是直通的设备功能。

Is the unit of assignment for an IO virtualization capable device. For example, a TDI may be an entire (physical) device, a non-IOV Function, or a virtual function (VF).

TDISP (TEE Device Interface Security Protocol)

这是一个 PCIe 6.0 中定义的 trusted I/O virtualization 标准，本身依赖于：

  • SPDM：是 control path。
  • PCIe IDE：MMIO DMA，是 data path。

TDI (TEE I/O Device Interface)

一个 TDI 只能被 assign 到一个 TVM，TDI 是 SR-IOV 或者 SIOV 中可以被 assign 的基本单元。有点像一个 VF。

每一个 TDI 都有很多可能状态，其中从 LOCKED 到 RUN 状态的转化只能由 TDI 所属的 TD 通过调用 TDCALL 的方式间接触发。

TSM (TEE Security Manager)

架构中就是 TDX Module。

DSM (Device Security Manager)

是设备上的一个组件。

TDISP-compliant device

TDISP-compliant device could host one or more:

  • TEE-IO Device Interfaces (TDI) which could be assigned to a single TD at any point-in time a time or;
  • alternatively, as regular device interface (e.g., VF) which can be assigned to TDs (via shared memory) or to regular VMs.

TSM (TEE security manager) / DSM (Device Security Manager)

因为这是一个 spec，具体的实现可能不同，因此 TSM 和 DSM 应该是两个抽象的称呼。

[!PDF|annotate] [[TDISP.pdf#page=10&selection=222,0,228,31&color=annotate|TDISP, p.10]] The TEE security manager (TSM) is a logical entity in a host that is in the TCB for a TVM and enforces security policies on the host.

[!PDF|annotate] [[TDISP.pdf#page=10&selection=228,31,235,91&color=annotate|TDISP, p.10]] The Device Security Manager (DSM) is a logical entity in the device that may be admitted into the TCB for a TVM by the TSM and enforces security policies on the device.

右边的 TSM 和 DSM：

![[TDISP.pdf#page=10&rect=87,150,526,510&color=annotate TDISP, p.10]]

作用：

![[TDISP.pdf#page=11&rect=69,643,543,723&color=annotate TDISP, p.11]]

SPDM (Security Protocol and Data Model)

是一个基于 PCIe 做的协议。

设备认证：SPDM 允许设备相互验证对方的身份，确保数据传输是在可信的设备之间进行。这可以通过证书、密钥交换和挑战 - 响应机制来实现。

SPDM 消息传递协议在两个 endpoints 之间定义了一个 request-response 消息传递模型，以执行 SPDM 消息交换中概述的 SPDM message exchanges。

SPDM 度量