机密计算实战：Intel TDX / AMD SEV-SNP / GPU TEE 的硬件级隐私保护生产部署

一、为什么需要硬件级可信执行环境

传统云计算的安全模型基于"信任云服务商"，但侧信道攻击（如 Spectre/Meltdown、L1TF）、恶意管理员、Hypervisor 漏洞等威胁模型打破了这一假设。可信执行环境（Trusted Execution Environment, TEE）通过硬件加密将"可信计算基"（TCB）缩小到 CPU 芯片本身，即使是拥有 root 权限的 OS 管理员也无法读取运行中的明文数据。

机密计算（Confidential Computing）将这一概念从移动端 TrustZone 扩展到数据中心级的全 VM/Container 加密运行。Intel TDX、AMD SEV-SNP 和 GPU TEE 分别从不同层级切入这个领域。

二、Intel TDX：Trust Domain Extensions 架构深度解析

Intel TDX（Trust Domain Extensions）是 Intel 在第四代至强可扩展处理器（Sapphire Rapids）及之后引入的机密计算硬件扩展。其核心思想是将 Hypervisor/KVM 排除在 TCB 之外，通过 CPU 硬件为"信任域"（Trust Domain）提供内存加密和远程证明。

2.1 架构组件

TDX 引入了三个核心角色：

• TD（Trust Domain）：被保护的虚拟机，其内存和寄存器状态使用 AES-256-XTS 实时加密
• SEAM（Secure Arbitration Mode）：Intel 硬件引入的更高权限模式，承载 TDX 模块代码，低于普通的特权级（VMX root）
• TD Module：运行在 SEAM 模式中的微软/Intel 联合实现的固件，负责 TD 生命周期管理

2.2 内存加密模型

TD 内存通过 MKTME（Multi-Key Total Memory Encryption）实现分区加密。每个 TD 拥有独立的加密密钥，TED（TD Encryption Engine）在 CPU 内存控制器级别透明地加密/解密所有内存访问。CPUID 的 SEAM 标志位确保加密密钥不会暴露给非 SEAM 模式的任何代码。

// 简化的 TDX 内存访问流程
CPU Core -> L1/L2 Cache (明文) -> TED Encryption Engine -> Memory Controller -> DRAM (密文)
                  ^                                         |
                  |---- 仅在 CPU 封装内部暴露明文 ----------|

2.3 远程证明（Remote Attestation）协议

TDX 远程证明是确保客户代码运行在真实 TDX 环境中的关键协议，流程如下：

1. TD 生成 REPORT 结构（包含 TD 测量值、TCB 版本等）
   - 通过 SEAMCALL[TDG.MR.REPORT] 指令

2. TDX 模块将 REPORT 封装为 "TD Quote"
   - 调用 Intel QE（Quoting Enclave，基于 SGX 的封印密钥服务）

3. Quote 发往 Intel PCS（Provisioning Certification Service）
   - 验证 TCB 版本是否为最新（若需升级则触发 SVU 流程）

4. 验证方（如用户客户端）校验 Quote 中的：
   - MRSERVER（初始度量值）
   - TD 的 TCB SVN（安全版本号）
   - QE 证书链（Intel 根 CA 签名）

三、AMD SEV-SNP：安全嵌套分页与完整性保护

AMD 的 SEV（Secure Encrypted Virtualization）经历了三代演进：SEV（仅内存加密）、SEV-ES（寄存器状态加密）、SEV-SNP（Secure Nested Paging，抗重放和完整性保护）。

3.1 反向映射表（RMP）

SEV-SNP 引入的关键创新是 RMP（Reverse Mapping Table），一个由 PSP（Platform Security Processor）维护的全局表，记录每个物理页的归属（哪个 VM 拥有它）和访问权限。这阻止了以下攻击：

• 重放攻击：Hypervisor 将内存页内容替换为旧版本
• 别名攻击：Hypervisor 将同一物理页映射到不同 Guest 造成冲突
• 完整性破坏：RMP 表中每个页面有一个计数器和 VMPL（VM Privilege Level）字段，写入时必须匹配

3.2 生产级部署：SEV-SNP + Kubernetes

在云原生环境中部署 SNP 机密计算：

# 使用 Confidential Containers (CoCo) 部署 SNP 机密 Pod
apiVersion: v1
kind: Pod
metadata:
  annotations:
    io.katacontainers.config.hypervisor.initrd: "true"
    io.katacontainers.config.hypervisor.ctd: "true"
spec:
  runtimeClassName: kata-cc
  containers:
  - name: secret-app
    image: registry.example.com/encrypted-app:latest
    resources:
      limits:
        confidential-compute: "1"  # 请求 TEE 环境
  # 通过 containerd 配置的 CoCo runtime 会：
  # 1. 从签名镜像获取远程证明
  # 2. 向 Key Broker Service 请求解密密钥
  # 3. 仅在通过证明后才注入密钥并启动 TD/SEV-VM

四、GPU TEE：NVIDIA 的机密计算扩展

大模型训练和推理的隐私保护需求催生了 GPU TEE。NVIDIA 在 Hopper 架构（H100）及后续产品中引入了 GPU 机密计算能力，支持 GPU 内部的 TEE。

4.1 GPU TEE 架构

GPU 侧 TEE 通过硬件隔离的"GPU Context"实现：

• GPU 内存通过硬件加密引擎保护（AES-256-GCM）
• GPU 调度器在 Host Driver 和 Firmware 之间隔离敏感上下文
• 支持 GPU 远程证明，可通过 NV 的 GPU Attestation Service 验证

4.2 生产模式：多租户 GPU 机密推理

将 GPU TEE 应用于 LLM 推理服务的隐私保护场景：

// 使用 NVIDIA TensorRT-LLM + GPU TEE 的推理流程
1. 客户端通过 HTTPS 发起推理请求
2. Client 端本地生成 enc-dec 密钥对，仅公钥随请求发送
3. 推理服务在 GPU TEE 内部：
   a. 加载加密的 ONNX/TensorRT 引擎
   b. GPU 固件用 TEE 私钥解密模型权重到 GPU 加密内存
   c. 执行推理（整个计算流水线不出 TEE）
   d. 结果用客户端公钥加密后传出
4. 客户端解密获得推理结果

// 全程 GPU 显存明文对 Host CPU 不可见

五、远程证明的互操作与标准化

2024 年以来，机密计算的 remote attestation 协议正在走向标准化：

• DICE（Device Identifier Composition Engine）：TCG 标准，支持层次化证书链
• RATS（Remote Attestation Procedures）：IETF 标准框架，TEE 供应商中立
• CoCo 的 Key Broker Service：CNCF 项目，标准化租户与 TEE 之间的密钥分发

六、性能开销与生产级考量

机密计算的性能开销因场景而异：

• 内存加密：TDX/SEV 的 MKTME 开销约 2-5%（随工作集增大）
• 远程证明延迟：首次证明请求可能需要 200ms-2s（取决于厂商 API）
• I/O 路径：virtio 加密 I/O 需要穿过加密边界，延迟增加 10-20%
• 调试困难：TD 内部无法使用宿主侧的 strace/gdb，需内置 TD 内遥测代理

七、总结与展望

机密计算正在从"安全象牙塔"走向生产级落地。Intel TDX 提供了最强的 VM 级隔离（跨越 VM 边界），AMD SEV-SNP 以反向映射表解决了完整性问题，NVIDIA GPU TEE 填补了 AI 推断的隐私空白。预计 2026-2027 年，随着 CCF（Confidential Computing Consortium）和 CUCC（Confidential Computing Consortium China）的推动，机密计算将成为金融、医疗、政务云等场景的标配安全能力。

对技术团队而言，当前最务实的切入点是：在合规要求严格的推理服务中，使用 CoCo + SEV-SNP 实现端到端的 TEE 化部署；在跨机构数据联合分析场景中，探索基于 TEE 的多方安全计算（MPC）替代方案。