Motivation of TDX

三个角度来说明为什么需要 TDX：

  • 客户（Tenant）角度：大模型安全，不希望自己的大模型训练/推理数据泄漏；
  • 云厂商角度（CSP）：基于客户需求，需要提供对于数据安全的强保证（强自证能力）,现有基于纯软件和 VMX 虚拟化架构无法做到这一点；
  • Intel：硬件直接保证安全性，Virtual Machine -> Trust Domain, Virtual Machine Extension (VMX) -> Trust Domain Extension (TDX)。

TDX 1.0 能做的：

  • Confidentiality（主要是运行时一些数据的机密性）
    • Memory Confidentiality
    • CPU-State Confidentiality
  • Integrity（主要是软件栈的完整性，防篡改）
    • Memory Integrity
    • Address-Translation Integrity
    • CPU-State Integrity
  • Secure Interrupt and Exception Delivery
  • Remote Attestation

可以参考下面的 threat model：

TDX 1.5 能做的：

  • TD Live Migration
  • TD Partitioning

TDX 2.0 (TDX Connect) 能做的：

  • TDX IO

TDX 不能做的：

  • Reliability: DDoS

TDX TCB 有哪些？能够防止哪些攻击？

![[TDX Whitepaper.pdf#page=2&rect=21,160,284,324&color=annotate TDX Whitepaper, p.2]]
![[TDX Whitepaper.pdf#page=8&rect=312,242,564,450&color=annotate TDX Whitepaper, p.8]]

Memory & CPU-State Confidentiality and Integrity

数据加密：

  • data in transfer：对应到网络数据的加密，依赖各种加密协议比如 SSL；
  • data in rest：对应到磁盘数据加密，不是 TDX 关注的重点；
  • data in use：CPU 运行时所依赖的存储器空间加密，注意这里的内存空间更广义（冯诺依曼结构里的存储器），包含寄存器信息/内存信息。TDX 主要解决这一点。

内存信息的安全性：

在目前的内存虚拟化模型中，Hypervisor 对于一个 guest 使用的 page：

  • 可以决定将哪一个 HPA assgin 给虚拟机来使用，也就是地址是不受保护的；
  • 可以直接访问对应内存页的内容，和访问 Host 上自己的内存页无异，也就是内容也是不受保护的；

寄存器信息的安全性：

VMX 中，vCPU 运行过程中的寄存器信息保存在 VMCS/APIC page 等当中，都是由 host 直接分配并完全访问的，因此可能会有数据泄漏的问题。但是其实 VMCS/APIC page 本质也是一块内存，只不过不是 guest 看得到的内存。因此，从 TDX 的角度，其应该解决的问题：

  • Guest 内内存加密
  • Guest 相关内存加密（Hypervisor 控制，并非 commit 给 guest 的内存）

上面两者对于 TDX 来说其实都是内存，TDX 因此基于一个硬件 feature，MKTME 来进行内存加密。

TME & MKTME for Confidentiality

TME 在硬件上引入了一个 AES XTS encryption engine:

  • 数据离开内存总线时：加密
  • 数据读入内存总线时：解密

加密 key：硬件生成，软件无法访问。

TME 的缺点是整个平台只能使用一把密钥来加密内存，不支持在系统里划分出多个基于加密密钥构建的加密内存 domain，MKTME 支持多个密钥；

  • 一把密钥仅仅能防止 Host VMM 对 TD 的攻击，无法防止 TD 间的攻击；
  • 多把密钥可以防止一个 TD 对另一个 TD 的攻击（使用不同 key）。

TDX Enhancement for Integrity

  • Memory write 的时候，更新 MAC;
  • Memory read 的时候，计算并比对 MAC。

MAC 作为 metadata，和写入的内存页内容放在一起。

When Ci mode is enabled, the CPU’s memory controllers compute a 28-bit integrity check value (MAC) for the data (cache line) during writes and store the MAC with the memory as meta-data.

TDX 引入了两个 mode：

  • Ci mode: Cryptographic-integrity mode;
  • Li mode: Logical-integrity mode.

Intel TDX may be enabled with a cryptographic-integrity protection mode using a SHA-3 based MAC (28-bit) on each cache line. In this mode, SHA-3-256 is used as the underlying function for MAC generation with the 256b output truncated to 28b for storage and verification. To help prevent ciphertext disclosure, a 1-bit TD-ownership tag is maintained with each cache line to identify if the line is associated with a memory page assigned to a TD. In this mode, the TD-ownership-bit is included in the MAC.

Optionally, a logical-integrity mode may be used, which maintains the 1-bit TD-ownership tag, however there is no cryptographic MACmaintained per cache line in the logical-integrity mode.

Address-Translation Integrity

传统的 EPT (share EPT) 是这样的：

防止被篡改，如果 EPT 能够被 KVM 直接控制，那么 KVM 可以将 TD 的访问导向任何 HPA，从而截获 TD 的内存访问/写入内容，会导致 TD 内容泄漏。KVM 也可以直接破坏 EPT 页表的内容，造成完整性的丢失。

TDX 为此使用了 Secure EPT 机制。Secure EPT 用来保证 translation 的完整性，其结构和 EPT 一样，但是 secure EPT 被 private key 保护，KVM 作为不被信任方，对 secure EPT 的修改会直接导致 host panic。

SEAM (Secure-Arbitration Mode), SEAMLDR, Intel TDX Module

有了 MKTME 等等的保护固然好，但是这让现在的软件栈的正常功能（非攻击链路）无法工作了：

  • KVM 无法直接操作 VMCS（vCPU 寄存器信息）进行一些重要功能比如中断注入，因为被 MKTME 保护着…
  • KVM 无法直接更新 secure EPT，那么就无法控制 guest 的地址翻译…

为了实现这些功能，引入一个中间者：Intel TDX Module，为了能够让硬件对 TDX Module 和 KVM 作区分，所以引入一个新 mode：SEAM Mode，其本身与 Ring 以及 VMX Mode 是正交的关系。TDX Module 是一个 firmware，TDX Module 与 TD 都工作于 SEAM Mode。

下图忽略了 Ring mode 这个维度，所以 TDX Guest 里的 app 和 Userspace VMM 比如 QEMU/Firecraker 没有显示在里面，也不重要：

TDX Module is hosted in a reserved, memory space identified by the SEAM-range register (SEAMRR).

只有运行 SEAMRR 中的代码，才能访问 SEAMRR 区间的数据。

In order to install the module for Intel TDX, a new, Intel TXT authenticated-code module (ACM), called the SEAM Loader (SEAMLDR), is provided to help verify the digital signature on the Intel TDX module and load it into the SEAM-memory range.

TDX Module 如何被 load？

VMM (KVM) load -> SEAMLDR -> Intel TDX Module.

Remote TD Attestation

另请参考关于 Attestation 的文章：[[Attestation on Intel Platforms]]。

TD Live Migration

TD Partitioning

TDXIO (TDX Connect)

参考 [[TDX Connect]] 文章。

改造成本

TDX 改造需要改的东西：

  • IFWI: 需要用到 Intel 提供的 ifwi，一些关于内存加密和 TDX 的选项需要在这里打开；
  • Intel TDX Module：需要从 Intel 处获取；
  • TDX host kernel patch：linux kernel 需要支持 TDX host kernel 这部分的 patch；
  • TDX KVM patch：KVM 需要支持 TDX；
  • TDX QEMU (Userspace VMM) patch：需要 userspace VMM 来使用；
  • TDX guest kernel patch：TDX 是一个半虚拟化方案，需要特定的 guest kernel patch 才可以用，比如 TDVMCALL 等等；
  • TDVF（基于 UEFI 的 VM BIOS）

TDX Performance

之前 Chao 一起写的性能评测文档：Performance Considerations: Intel® Trust Domain Extensions

总结下一些可能影响性能的因素：

  • 因为相比于 VMX 多了 SEAMCALL，我们可以 tune software to reduce the Intel TDX transition rates, for example, by using polling mode I/O threads or by reducing timer ticks. To reduce the effect of memory copy overhead and to improve overall I/O performance, Intel will introduce TDX Connect in future Intel CPU generations.也就是多了 SEAM Mode 之间的转换。
  • 因为 MKTME 会对内存加解密，A read operation can experience additional latencies depending on the DRAM speed while the overhead in write operations is less apparent due to the write back nature of the CPU cache.
  • Remote memory accesses are encrypted over Intel UPI and thus can experience additional latencies，最好不要跨 NUMA。
  • 没有 TDX Connect 的情况下，有内存拷贝开销，shared memory (bounce buffer) <-> private memory。

评测：CPU 内存密集型和 IO 密集型两类 benchmark。

CPU/内存密集型负载测试结果

  • 测试负载包括 SPECrate 2017（整数和浮点计算密集型）、SPECjbb 2015（Java 应用性能）、LINPACK（高性能计算负载）和 TensorFlow BERT（机器学习负载）。
  • 在这些负载下，TDX 的性能影响通常在 5% 以内。例如：
    • SPECrate 2017 整数和浮点负载性能下降约 3%。
    • SPECjbb 2015 性能下降约 4.5%。
    • LINPACK 性能下降约 2.77%。
    • TensorFlow BERT 性能下降约 3.81%。
  • 性能影响主要来源于内存加密和 TDX 转换，尤其是由于本地 APIC 计时器中断引起的转换。

I/O 密集型负载测试结果

IO 次数越多，数据传输速率越大，性能越差。主要原因：

  • Transition 变多
  • bounce buffer

解释结果：

  • 测试负载包括 Memtier（Redis 内存数据库的读写操作）和 HammerDB（MySQL 数据库的事务处理）。
  • HammerDB 其实是故意设置成最差的设置，50GB 数据库大小，5GB buffer on 32GB guest。性能下降约 9.3%。
  • Redis-memtier 在不同配置下性能影响从 3.6% 到 25% 不等，具体取决于 vCPU 的利用率和 I/O 操作的频率。

Non-confidential / Legacy 在 IO 情况下也几乎没有影响。

Noisy neighbor

一共 56 cores，8 cores for host，48 个核给 6 个虚拟机，每一个虚拟机 8 个核。benchmark 使用 CPU 访存密集型的 SPEC 2017。实验配置：

结论：影响不大。

TDX 常见问题备忘

TDH.VP.RD/TDH.VP.WR 是否会毁坏对于 CPU 运行状态机密性的保护？

不会，TDH.VP.RD/TDH.VP.WR are only allowed to access non-secret TD VCPU state in TDVPS when debug mode is off.

数据在 CPU 和 cache 中仍然是明文的，所以 TDX 能防止 side channel attack 攻击吗？