机密计算（TDX/SGX/CCA/SNP/CoCo）

• TDREPORT 结构及其字段（MRTD、RTMR、其他配置信息）
• MRTD（Measurements of TD）与 RTMR（Runtime Measurement Registers）的语义区别
• 远程证明（Remote Attestation）中测量值如何被验证

TDX 的信任链建立在测量之上。TDREPORT 是 TD 在启动时由 TDX Module 生成的一个结构，其中关键字段包括 MRTD（反映 TD 构建时不可变度量，包括 TD 的初始代码、页表、配置等）和 4 个 RTMR（Runtime Measurement Registers，记录运行时动态加载的模块、如 VMM 后加载的代码、用户态应用等）。TD 可以使用 TDCALL 指令（如 TDCALL 的 TDG.MR.REPORT 叶子）向 TDX Module 请求生成签名后的 TDREPORT，由 TDX Module 用其私钥（对应平台上的 Quote Enclave 证书链）签名，确保只有真实可信的 TDX Module 才能伪造。验证方通过 Quote 验证流程，将 TDREPORT 中的测量值与已知的"良好"参考值比对，从而确认 TD 运行的是可信的镜像，且未被篡改。工程价值在于：MRTD/RTMR 建立了从硬件到 VMM 再到 TD 内应用的完整度量链，使"信任"不再是早期的静态能力，而是可程序化校验的证据，支持大规模云环境中的机密 VM 差异化策略。

测量值（Measurements）是远程证明的基石——它把"内存里实际加载了什么"变成密码学上可验证的摘要。MRTD 固定于启动点，RTMR 允许运行时扩展，二者配合既保证启动不可篡改又允许动态加载，是 TDX 相比纯静态信任链（如单一 TCB）更灵活的原因。

• EPC 与 TDX 中共享内存（shared EPC）的概念
• TDX 1.5 Connect 的跨 TD 通信/共享机制
• 与 SGX 的 Enclave 内共享的异同

TDX 1.5 Connect 引入了对共享 EPC 的支持，使得多个 TD 之间可以共享加密的 EPC 页面，并在这些页面上进行受控的数据交换。此前 TDX 中 TD 与 TD 之间默认是强隔离的，跨 TD 通信只能通过共享内存（shared memory，非 EPC）配合 VMM 或主机进行，而 TDX 1.5 Connect 让多个 TD 可以在可信的 EPC 内共享页面，从而在保持机密性（内存加密）的同时，实现类似微服务/多 TD 协作的低开销数据通道。工程价值在于：它补齐了 TDX 生态中"多 TD 协作"场景，使大型机密工作负载可以拆分为多个 TD 而无需把数据降到非加密内存，同时仍由 TDX Module 保证共享页面的访问控制。

多 TD 协作是机密计算的现实需求（如把密钥管理、计算、认证拆成不同 TD）。共享 EPC 让这些 TD 在加密内存内交换数据，避免机密数据落盘到宿主可见内存，兼顾隔离与协作。

• TDX Module 与 KVM 的职责分工
• qemu-tdx 作为 TDX-aware VMM 的角色
• 安全边界划分（哪些必须有 TDX Module 参与，哪些由 KVM 处理）

TDX 2.0 中，TDX 承担机密性职责，KVM 承担虚拟化职责，二者通过明确的接口（如 TDCALL/TDG.VM.* 与之对应）协同。TDX Module 运行在 SEAM 模式（SEAMRR 保护的隔离内存中），负责 TD 的创建、内存加解密、度量（TDREPORT）、TD-Exit/TD-Enter、以及所有涉及 TD 机密性的操作；KVM/QEMU 作为 TDX-aware VMM，负责 TD 的调度、虚拟设备模拟、中断/虚拟化等非机密性工作，但凡是涉及 TD 内存加密、EPT 安全、TD VMCS 等，都必须下沉到 TDX Module 并通过 TDCALL 完成。工程边界的关键在于：VMM 永远不能直接访问 TD 的机密内存（只能通过 TDCALL 间接操作），从而保证即使 VMM 被攻破，TD 的机密性也不受影响。qemu-tdx 就是这样一个对 TDX 2.0 进行了适配的 QEMU 版本。

安全边界清晰是机密计算的关键设计——把"必须信任"的代码压到最小（TDX Module），把"可被攻破"的 VMM 限定在不可触及机密内存的范围内。TDCALL 是硬件指令，保证 VMM 无法绕过。

• SEAMRR 的作用与原理
• SEAM（Secure Arbitration Mode）内存的安全隔离
• 对 TDX 信任根（TCB）的贡献

SEAMRR 是一组 MSR（模型特定寄存器），用于划定 SEAM 内存的物理地址范围。SEAMRR 配置后，只有运行在 SEAM 模式（SEAM root mode）的代码（即 TDX Module）才能访问该范围内内存，普通软件（包括 host VMM、OS、IOMMU 等）都无法读写 SEAM 内存。这为 TDX Module 本身提供了强隔离的信任根：TDX Module 的代码、目录结构（如 TD、EPC 管理元数据）都存在于 SEAM 内存中，即使整个操作系统与 VMM 被攻破，攻击者也无法篡改 TDX Module 或伪造 TDREPORT。工程价值在于：SEAMRR 把"不可信"的 HOST 与"可信"的 TDX Module 在物理上隔开，建立了机密计算的最底层信任边界，是 TDX 远程证明可信性的根基。

信任必须建立在不可被篡改的地方。SEAMRR 用硬件 MSR 划定并锁定内存范围，让 TDX Module 拥有独立的、不可被软件访问的代码/数据空间，从而保证测量与证明的完整性。

• sgx_seal_data 密封数据（sealing）的作用
• sgx_increment_counter 单调计数器的用途
• 两者在安全存储/防重放场景的应用

sgx_seal_data 是 SGX 的密封（sealing）API，它利用 enclave 派生的密钥（密封密钥，基于 enclave 身份与 CPU 的硬件密钥）对数据进行加密后存储到非机密内存/磁盘，从而让 enclave 可以持久化状态而不泄露机密。sgx_increment_monotonic_counter（SGX SDK 单调计数器 API，即题述 sgx_increment_counter）提供单调递增计数器，用于防重放（anti-replay）与防回滚（anti-rollback）——例如防止攻击者把已密封的旧状态重新提交，或用旧备份回滚数据库。二者常配合使用：用 seal 加密保存状态，用 monotonic counter 或额外签名记录版本，检测重放。工程价值在于：为 enclave 提供了"安全持久化"与"状态防篡改"这两个机密计算中易被忽略却至关重要的能力。

加密封存解决"机密数据如何离开 enclave 仍安全"，单调计数器解决"如何防止已封存数据被回滚"。这二者是 SGX 应用真正落地（如密钥管理、机密数据库）的必备构件。

• SNP 多密钥（multiple keys）的硬件缓存
• 多密钥缓存的工作原理与价值
• 对多租户/多 VM 场景的影响

SNP 早期版本在一次内存加密中通常只能缓存有限数量的密钥（如 Naples 时代每插槽仅约 15 个可用密钥，Milan 为 509 个 ASID），导致频繁切换 VM 时需要重新加载密钥，产生较高的上下文切换开销。SEV-SNP 3.0 的 Multikey Caching 支持在硬件缓存中同时缓存多个（多个 VM 的）密钥，从而在多个机密 VM 之间快速切换时减少密钥重新加载（key reload）引发的开销，提升多租户场景下的吞吐与延迟表现。工程价值在于：它是"多 VM 并发机密计算"的现实基础，让云平台能高效运行大量相互隔离的 SEV-SNP 虚拟机，而无需为每次调度付出密钥加载的代价。

密钥切换开销是 SEV-SNP 多租户化的瓶颈。Multikey Caching 用硬件缓存多个密钥换取低延迟切换，属于典型的"用硬件资源换性能"的机密计算优化。

• EATX 的含义与背景
• x2APIC 虚拟化在 TD 中的意义
• 对中断性能和 TD 隔离的影响

EATX（Extended APIC virtualization）是 TDX 2.0 引入的扩展 APIC 虚拟化能力，用于在 TD 中支持 x2APIC 系虚拟化。在 TDX 1.0 中，TD 内 APIC 虚拟化能力受限，通常需要使用虚拟 APIC 页（virtual APIC page）或通过 VM-Exit 模拟，带来额外开销或限制。EATX 允许 TD 更高效地使用 APIC 虚拟化特性（如叶子中断、更快的 MSR 访问），从而减少中断处理导致的 exit 开销，提升 TD 内 I/O 密集与多核工作负载的性能。工程价值在于：它让机密 VM 也能享受与普通 VM 接近的 APIC 虚拟化性能，同时保持 TD 的隔离与机密性。

中断虚拟化性能直接影响 I/O 吞吐。EATX 把 x2APIC 的高效虚拟化带入 TDX，是"机密性不牺牲性能"的典型努力。

• Occlum 的 LibOS 架构
• musl libc 在 enclave 内运行的意义
• 与 Direct 调用（如 SGX SDK）相比的优势

Occlum 是一个基于 Library OS（LibOS）的机密计算运行时，用于 SGX 与 TDX。它把 musl libc 和 Linux 系统调用接口（POSIX 语义）编译进 enclave，使应用无需针对 SGX 的本地调用（OCALL/ECALL）重新编写，即可在 enclave 内以接近原生 Linux 的方式运行。musl libc 体积小、静态化友好、易移植，适合放进 enclave 受限的地址空间。Occlum 通过多进程、多线程、文件系统等 LibOS 抽象，让"unmodified" 应用较容易迁移到机密环境。工程价值在于：大幅降低机密计算的应用移植门槛，让通用二进制/框架能在 SGX/TDX 上运行，同时仍由 enclave 保证内存机密性。

SGX 的 ECALL/OCALL 模型对应用侵入大。LibOS 用"把系统调用留在 enclave 内"的方式隐藏这一切，musl 提供轻量 POSIX 层，是实现"应用零改造"的关键。

• secure EPT 与普通 EPT 的区别
• 页表跟踪（tracking）与 dirty-bit 的作用
• 对热迁移与内存管理与安全的影响

secure EPT 是 TDX 2.0 用于管理 TD 内存页表（EPT）的加密/受保护机制。TDX 会保护 TD 的 EPT 不被 VMM 篡改，同时允许 VMM 通过必要的接口驱动页表更新。dirty-bit（脏位）标记用于记录哪些页被写，这在热迁移（live migration）中尤为关键——迁移时只需拷贝脏页。在 TDX 2.0 中，secure EPT 的跟踪与 dirty-bit 协同，使 VMM/协调器能在 TDX 机密内存场景下高效执行迁移和内存回收，同时保证 EPT 内容与 TD 度量的一致性与安全性。工程价值在于：让机密 VM 也能实现与普通 VM 相似的热迁移与内存管理能力，而不破坏机密性。

机密计算的难点之一是"既要保护页表不被改，又要让系统能管理内存"。secure EPT 结合 dirty-bit 给出答案：加密保护页表结构，用脏位做高效迁移，兼顾安全与性能。

• SEAM root mode 与 SEAM VMX root 的关系
• root mode 升级的能力与意义
• 对 TDX 功能演进的影响

TDX 的 SEAM 模式运行在 SEAM root mode（VMX root 下的一层特殊模式），由 TDX Module 使用。TDX 2.0 对 SEAM root mode 进行了能力升级，使 TDX Module 能够执行更丰富的资源管理、状态切换与更复杂的 TD 操作（如更高效的内存管理、动态 EPT 处理、改进的 TD-Exit 处理）。这种"root mode 升级"本质上是扩大 TDX Module 在 SEAM 下的特权操作集，让 TDX 能够推出新功能（如 TDX 2.0 的活跃 EPT、VM 迁移增强等）而不改变硬件信任模型。工程价值在于：SEAM root 的可升级性让 TDX 在保持硬件信任根的前提下不断演进，支撑新特性落地。

SEAM root mode 是 TDX Module 的"特权世界"，其能力直接决定 TDX 能做什么。升级它意味着 TDX 功能集扩容，是 TDX 2.0 相对 1.x 能力增强的结构性基础。

• SGX2 动态内存管理（EDMM）的能力
• EPC 页面的动态添加/移除
• 相对 SGX1 固定内存的优势

SGX1 中 enclave 的 EPC 内存必须在创建时一次性确定，无法动态扩展，这限制了应用的内存灵活性。SGX2（动态内存管理，即 EDMM）引入 SGX 指令（如 ENCLS 系列的 EADD/EAUG/EMODPR 等），允许 enclave 在运行时动态添加、移除或修改 EPC 页面（包括设置权限、扩展栈/堆等）。SGX SDK 2.25+ 提供了对这些新指令的库封装，使开发者能按需增长 enclave 内存。工程价值在于：消除了 SGX1 的"内存上限"痛点，让动态内存应用（如按需分配、private 堆/栈）能平滑迁移到 enclave，显著提升 SGX 的实用性。

固定内存是 SGX1 的最大可用性限制。SGX2/EDMM 用动态页面管理解决它，SDK 封装让上层无需直接操作底层指令，是"硬件能力到开发者可用"的关键闭环。

• EPID 与 DCAP 两种 SGX 证明方式
• EPID 退役的原因（隐私、可扩展性、数据中心场景）
• DCAP 在数据中心/云环境中的优势

EPID 是 SGX 早期的一种匿名组签名证明机制，可在不泄露平台身份的情况下证明归属 SGX 家族，常用于 x86 客户端/消费场景，但需要与 Intel 服务交互、且匿名性在数据中心并不必要。DCAP（Data Center Attestation Primitives）面向数据中心，采用基于 X.509 证书链的本地证明架构，无需依赖 Intel 在线服务，使 cloud 可按需本地验证 Quote，并支持 SGX 的 ECDSA 签名。SGX SDK 自 2.25 起全面转向 ECDSA/DCAP 体系，EPID 相关功能在 SDK 2.28 中被正式移除（此前已宣布弃用），因为 DCAP 更适合自动化、可扩展、离线可用的云环境。工程价值在于：DCAP 让数据中心/云能够以标准的证书链方式大规模、低延迟地验证 enclave，降低对 Intel 服务的依赖，是 SGX 在云上落地的主流路径。

EPID 的匿名性与在线服务依赖不适合数据中心。DCAP 用本地证书链，把验证权交给平台，更强于可扩展性与离线可用，是 SGX 云化演进的方向。

• RMM 的角色与世界模型（Root/Realm/NS）
• Realm 世界切换的机制
• RMM 对 Realm 隔离的保障

ARM CCA 引入独立的 Realm 世界（Realm World），与普通非安全世界（NS、Rich OS）隔离。RMM 是运行在最高特权（Root World）的固件，负责管理 Realm，包括 Realm 的创建、内存（GPA→PA 映射）、以及 Realm 世界的切换（Realm ↔ NS 上下文切换）。RMM spec 1.0+ 定义了稳定的 RMM 接口（RMM interface），允许 hypervisor 通过该接口请求 RMM 进入/退出 Realm 世界，RMM 负责保存/恢复 Realm 状态、切换属性和内存保护。工程价值在于：RMM 作为"Root World 中的可信管理面"，把 Realm 的隔离与切换权集中到受保护的固件，让 hypervisor 无法直接触碰 Realm 机密，建立了 CCA 的信任根。

Realm 世界切换是 CCA 的核心操作，必须由不可被 NS 软件篡改的 RMM 执行。RMM 在 Root World 规格化接口，保证切换既安全又可被上层（hypervisor）驱动。

• RTT（Realm Translation Table）的概念
• RTT 与 stage-2 页表的关系
• 对 Realm 内存隔离与机密性的保障

在 ARM 虚拟化中，stage-2 页表用于 hypervisor 把 Guest 的 IPA 翻译到物理地址。在 CCA 中，Realm 的内存必须由 RMM 管理，RMM 使用 RTT（Realm Translation Table，即 Realm 的 stage-2 页表）来管理每个 Realm 的 IPA→PA 映射，并被 RMM 用硬件保护（GMP 等机制）。RTT 与普通 stage-2 页表协同：Realm 的 IPA 翻译由 RMM 的 RTT 完成，而普通世界的 stage-2 由 hypervisor 管理；两者在物理地址解析上衔接，但 RTT 的机密页面转换受 RMM 控制，防止 hypervisor 窥探 Realm 内存。工程价值在于：RTT 让 Realm 的地址翻译完全脱离 hypervisor 控制，从而保证 Realm 内存的机密性与完整性，实现 CCA 对"运行时不可信 host"的隔离承诺。

地址翻译即权限控制。RMM 用受保护的 RTT 接管 Realm 的 stage-2 翻译，杜绝 hypervisor 篡改页表或窥探机密，是 CCA 隔离的核心机制。

• RSI 的定义与作用
• host 与 Realm 之间的调用方式
• RSI 对机密性保护的意义

RSI（Realm Service Interface）是 RMM 提供给 Realm 内部软件调用的接口（通过 SMCCC 等机制），以及 Realm 与 host（hypervisor）之间受控交互的通道。Realm 内的软件可以通过 RSI 向 RMM 请求服务（如内存委托、attestation 请求、realm 生命周期操作），而 host 也能通过 RSI 触发的机制与 Realm 协调。RSI 设计的关键是：host 与 Realm 的交互必须经过 RMM 这一可信边界，Realm 可以决定是否响应 host 的请求，从而防止 host 监听或篡改通信。工程价值在于：RSI 提供了规范的、受 RMM 保护的 host↔realm 调用协议，使 hypervisor 与 Realm 协作的同时不破坏机密性，是 CCA 生态可编程性的基础。

没有受控的接口，host 与 Realm 只能靠共享内存裸通信，机密性无保障。RSI 把交互纳入 RMM 管辖，既提供功能又保住隔离。

• CCA Realm Token 的作用
• EAT（Entity Attestation Token）格式
• 与标准证明格式的互操作性

CCA 的 Realm 通过 RMM 请求生成 attestation token，用于向验证方证明 Realm 的度量、身份与平台可信性。该 token 采用 EAT（Entity Attestation Token，RFC 9100 定义的基于 CBOR/JSON 的通用证明格式）来表达，内含 Realm 的度量值、平台配置、RMM 版本等 claims。EAT 的好处是标准化、跨厂商可互操作、可扩展（支持自定义 claims）、且轻量（适合受限环境）。工程价值在于：CCA 用 EAT 这种开放标准格式，让 Realm 的证明能与其他证明框架（如 TPM、SEV、TDX 的证明）在统一生态中互认，降低了验证方集成成本，也便于把区测量、SP（Security Protocol）等语义标准化表达。

证明格式的标准化决定生态互操作性。EAT 以其通用性和可扩展性成为 CCA 与多种证明体系对接的桥梁，避免厂商锁定。

• TEE-GPU / confidential compute 的 GPU 机密计算需求
• Blackwell B200 相对 Hopper H100 CC 的演进
• 机密 GPU 与 CPU TEE（如 TDX/SEV-SNP）协同的信任链

GPU 机密计算（confidential compute on GPU）用于保护 AI 训练/推理中的模型权重与数据在 GPU 内存中不被宿主窥探。Hopper H100 推出 Confidential Computing（CC）能力，允许 GPU 内存加密并支持与 CPU TEE 的信任链。Blackwell B200 作为继任者，在其 TEE-GPU 模式下增强了 GPU 内存加解密、GPU 与 CPU TEE（如 TDX/SEV-SNP）之间的远程证明与信任建立，以及更大的密钥/内存保护域，使大规模 AI 工作负载能在机密环境中运行。工程价值在于：让"机密计算 + AI"成为可能——保护模型与数据的同时利用 GPU 算力，支持金融、医疗、多租户 AI 云等对数据主权要求高的场景。

数据在 GPU 内存中同样需要保护，否则 CPU TEE 是"装修了一半的房子"。Blackwell 的 TEE-GPU 把加密与证明扩展到 GPU，补齐了 AI 机密计算的关键一环。

• SNP 的迁移保护机制
• 迁移的合法性验证与密钥转移
• 在云平台容灾/负载均衡中的价值

SEV-SNP 早期版本对迁移支持有限，因为迁移把加密 VM 的内存从一台物理机搬到另一台，涉及密钥转移与迁移合法性验证，若处理不当会破坏机密性或被恶意迁移。SNP Active Migration 定义了受控的迁移流程：源 SNP 与目标 SNP 通过迁移代理（Migration Agent）交换密钥，验证迁移请求的合法性，把 VM 内存重新加密后迁移到目标平台，从而既支持 VM 可移动性（容灾、负载均衡、热迁移）又保持机密性。工程价值在于：让机密 VM 像普通 VM 一样可迁移，这对云平台的高可用、资源调度至关重要，同时通过迁移代理保证不会把 VM 迁移到不可信平台。

机密 VM 的迁移难点在"密钥与内存一起搬迁且不泄露"。SNP Active Migration 用迁移代理 + 密钥转移协议解决，兼顾可移动性与安全。

• RMP（Reverse Map Table）的作用
• 页面状态机（page state machine）的语义
• RMP 对内存完整性/隔离的保障

RMP（Reverse Map Table）是 SNP 维护的、与物理内存页一一对应的表，记录每页的归属（哪个 VM 拥有、会话密钥、状态）。SNP 通过 RMP 的页面状态机管理页面的生命周期：页可处于 Private（私有，仅归属 VM 可访问）、Shared（共享）、Hypervisor（宿主所有）等状态，并在分配、委托、回收、迁移时进行状态转换。任何访问（包括 DMA）都会由硬件检查 RMP，防止宿主或恶意 VM 访问他人私有页，从而在硬件层面实现内存隔离与完整性。工程价值在于：RMP 让 SNP 的内存保护从"仅加密"升级为"加密 + 完整性 + 访问权控制"，有效抵御恶意 VMM 的篡改与重放攻击。

加密只防窥探，防篡改需要完整性检查。RMP 的页面状态机把"谁能访问哪页"固化到硬件，拒绝宿主对私有页的越权访问，是 SNP 的核心保护机制。

• 嵌套 SNP 的场景（嵌套虚拟化）
• 嵌套页表与 RMP 的协同
• 多层虚拟化下的安全边界

嵌套 SNP 指在 SEV-SNP VM 之上再运行虚拟化（VM 里再开 VM，即 L0/L1/L2 多层）。此时需要多层页表（guest 的页表、L1 hypervisor 的 stage-2、以及 L0 的保护机制）协同，RMP 需要支持多级所有关系，确保每一层 VM 的私有内存只被其所属层访问。工程边界在于：RMP 的检查必须贯穿嵌套层级，L1 的机密 VM 私有页不能被 L1 自身乃至 L0 恶意访问，同时嵌套页表翻译要正确。SNP 3.0 通过扩展 RMP 与嵌套支持，让"VM 内的机密 VM"成为可能。工程价值在于：支撑云中云（如托管服务里再开机密 VM）、开发/测试环境中的嵌套虚拟化，同时保持每一层的机密性。

嵌套虚拟化把"谁可信"的问题叠加到多层。SNP 的 RMP 必须识别并隔离每一层 VM 的私有页，这是嵌套机密计算能否成立的关键边界。

• CoCo 项目的目标与架构
• kata-runtime 作为机密 VM 运行时
• 基于 TDX/SEV-SNP 的硬件机密 VM

Confidential Containers（CoCo）是面向 Kubernetes 的机密容器项目，目标是让现有容器工作负载无需重写即可运行在机密计算环境中。它采用 kata-runtime（基于微 VM 的容器运行时）作为核心：每个容器/容器组被装入一个由 TDX/SEV-SNP 保护的机密 VM（Guest VM）中，容器镜像被拉取后在机密 VM 内校验并运行，内存由硬件加密，宿主与 hypervisor 无法窥探。CoCo 通过镜像签名、远程证明、镜像解密的联动，保证"从镜像到运行"的完整可信链。工程价值在于：把机密计算从"裸 VM"提升到"容器"粒度，让云原生应用（K8s）直接获得机密性，降低了机密计算在云原生生态的落地门槛。

用户要的是"容器即机密"，而不是自行管理机密 VM。CoCo 用 kata 的机密 VM 封装 + TDX/SEV-SNP 硬件保护，把机密性无缝嵌入 K8s 工作流。

• Primitives-from-Linux 的含义
• Sapphire Rapids（SPR）IMC 的作用
• 硬件与软件协同的边界

"Primitives-from-Linux" 指的是 SGX 在新的平台上（如 Sapphire Rapids）利用 Linux 内核提供的原语与驱动来支撑 SGX 功能，而非完全依赖专用硬件固件。Sapphire Rapids（SPR）是 Intel 服务器 CPU，其 IMC（Integrated Memory Controller）与内存加密/MKTME 相关能力参与 SGX 的 EPC 管理。SGX SDK 2.25+ 需要与 Linux 内核对 EPC 的分配、sgx_enclave 管理、以及 IMC 的加密/密钥管理协同。工程边界在于：EPC 的分配与回收由内核驱动（如 /dev/sgx_*）管理，而加密的机密性由 IMC 的硬件密钥保证，SDK 只负责把 enclave 的创建、加载、调用映射到这些内核接口。工程价值在于：让 SGX 在 SPR 等新平台通过标准 Linux 内核路径运行，提升可维护性与可移植性。

SGX 落地需要内核提供 EPC 管理接口，硬件（IMC）提供加密。SDK 处于中间层，把应用请求翻译成内核原语，边界清晰，保障安全与可维护。

• CCA 的开放生态与厂商支持
• RMM 在不同 ARM 平台的移植
• 硬化与合规边界

ARM CCA 的 RMM 是一套由 ARM 主导、与硬件相关的固件，其工程实现需针对不同厂商的 ARM 平台做适配。NVIDIA、NXP、Ampere 等厂商提供或计划支持 CCA 的处理器各有差异（内存控制器、页表粒度、安全协处理器、虚拟化扩展等），因此 RMM 的实现需要在这些平台上移植、验证并满足各自的硬件约束。工程边界在于：RMM 既要遵循 ARM 的 RMM spec（保证接口与语义一致），又要适配各平台特有的内存加密、安全中断、平台安全固件（如 EL3/TrustZone）等细节。工程价值在于：CCA 的开放性与多厂商支持让机密计算避免单一厂商锁定，形成可互操作的 ARM 机密计算生态。

机密计算的价值在于生态。RMM 的 spec 与多厂商移植并行，决定了 CCA 能否在异构 ARM 服务器上统一落地。

• containerd-shim 的作用
• shim-runtime 在 CoCo 中的角色
• 运行时 shim 对容器生命周期管理的影响

containerd-shim 是 containerd 与容器运行时（如 runc/kata）之间的守护进程，负责承载容器进程、管理容器生命周期、转发 I/O 与日志，并让 containerd 与容器解耦（containerd 重启不影响容器）。CoCo 的 shim-runtime 在 containerd-shim 基础上扩展，加入了机密计算相关能力：与 kata-runtime 的机密 VM 交互、处理镜像解密的密钥、执行基于 TEE 的 attestation 等。工程价值在于：shim-runtime 让 containerd 以标准 shim 协议接入机密容器，使现有 K8s 平台无需改动即可使用 CoCo，同时把机密生命周期管理（如 VM 启动、证明、密钥注入）封装在 shim 层。

shim 是 containerd 与运行时之间的"适配器"，CoCo 在其上注入机密能力，是"尽可能复用现有云原生栈"的工程智慧。

• operator 模式与 CRD 的概念
• attestation controller 的职责
• 与 K8s 控制面的协同边界

CoCo 的 operator 采用 Kubernetes operator 模式，通过 CRD（Custom Resource Definition）定义机密计算相关的自定义资源（如密钥、镜像策略、attestation 配置等）。attestation controller 作为 operator 的一部分，监听这些 CRD 资源，协调机密 VM 的远程证明、密钥注入与策略校验，并驱动相关工作负载的创建。工程边界在于：attestation controller 负责"控制面"的编排与校验（如验证 Quote、决定密钥是否发放），而实际的机密 VM 运行与数据加密仍由 runtime/shims 与硬件 TEE 完成，二者通过 CRD 与字段进行状态同步。工程价值在于：用 Kubernetes 原生方式（CRD/operator）把机密计算策略变成可声明、可审计、可自动化的资源，降低运维复杂度。

K8s 的声明式管理靠 operator 与 CRD。把 attestation 逻辑做成 controller，让机密计算的策略与运维融入 K8s 控制面，是云原生机密计算的关键。

• Constellation 的定位与架构
• always-encrypted 集群的实现方式
• 与硬件 TEE（TDX/SEV-SNP）的结合

Constellation 是由 Edgeless Systems 推出的"always-encrypted" Kubernetes 发行版，它把所有节点（包括控制面与工作节点）都运行在机密 VM（如 TDX/SEV-SNP/SEV）中，使整个集群的数据（包括内存数据、节点间通信、etcd 等）都处于加密与受保护状态。其核心是把"信任"从"信任云运营商"转移到"信任硬件 TEE"，在节点上通过远程证明验证每个节点的完整性，并在节点间建立加密通信。工程价值在于：让用户无需修改应用即可获得一个"默认加密、默认可证明"的 K8s 集群，尤其适合多租户、数据主权敏感与合规要求高的场景。

传统 K8s 依赖云运营商的信任。Constellation 把信任根下沉到硬件 TEE，并用远程证明保证每个节点可信，实现"集群级机密计算"。

• 控制平面节点的机密化
• 控制平面 attestation 的机制
• 对集群整体可信性的贡献

Constellation 将 Kubernetes 控制平面（API Server、etcd、controller-manager、scheduler）也运行在机密 VM 中，并对其执行远程证明（attestation）。控制平面是集群的信任中枢，若被攻破则整个集群不可信。Constellation 在节点启动时用 TEE 的 Quote 验证其度量与配置，确认为可信的 Constellation 镜像后才允许其加入集群并参与共识；etcd 的密钥也只在可信的控制平面节点内可见。工程价值在于：把集群的"根信任"建立起来——控制平面可信，则其下管理的所有工作负载与密钥才能被信任，构建了端到端的可信链。

控制平面是密码学意义上的信任根。attestation 保证控制平面节点未被篡改，是其签发的密钥与策略可信的前提。

• Constellation 与 CoCo/Kata 的定位差异
• 分层架构（集群级 vs 容器级）
• 协同方式与边界

Constellation 是"发行版/集群级"机密计算方案，把整个 K8s 集群（含控制面）变成机密环境；CoCo/Kata 是"容器/工作负载级"方案，把单个容器封装进机密 VM。二者分层互补：Constellation 提供集群与节点的可信基座（可信节点、控制面、节点间加密），而 CoCo/Kata 处理工作负载的机密容器化与证明。协同边界在于：Constellation 保证"平台可信"，CoCo/Kata 保证"具体工作负载可信"，两者可叠加使用——在 Constellation 的可信集群上运行 CoCo 机密容器，形成纵深防御。工程价值在于：让云原生机密计算具备"集群 + 容器"双层的完整防护。

机密计算与容器生态需要分层覆盖。Constellation 管"地"，CoCo/Kata 管"房"，组合起来覆盖从节点到工作负载的完整可信面。

• TDX 1.5 Connect 的迁移能力
• 机密 VM 热迁移的密钥与状态处理
• 对云平台可用性的价值

TDX 1.5 Connect 引入了对 TD（机密 VM）迁移的支持，包括 live migration 的机制。它提供与迁移相关的 metadata 与密钥管理接口，使 TD 及其加密内存状态能够从源平台转移到目标平台，同时保持机密性——迁移过程中需要把 TD 的密钥、度量、状态安全地转移，并验证目标平台的可信性。工程价值在于：让 TDX 机密 VM 具备与普通 VM 类似的迁移能力（容灾、负载均衡、维护），显著提升机密 VM 在云中的可用性与运维性，否则机密 VM 一旦部署就"钉死"在物理机上，不切实际。

迁移是云运维的基本能力。TDX Connect 的迁移支持让机密 VM 不再绑定物理机，兼顾机密性与可移动性。

• TD 间远程证明（TD-TD attestation）的需求
• attestation protocol 的作用
• 与宿主平台证明的边界

TDX 1.5 Connect 支持 TD 与 TD 之间的直接远程证明（TD-VM ↔ TD-VM attestation），即两个机密 VM 之间相互验证对方是可信的、运行了预期的镜像，从而建立相互信任后再进行合作通信。该 protocol 让 TD 能交换并验证彼此的 TDREPORT/Quote 及度量，常用于多 TD 协作（如前端 TD 与后端密钥 TD）场景。工程边界在于：TD-TD 证明需要平台提供可验证的 Quote（由 TDX Module/Quote Enclave 生成），而 TD 间的信任建立在"各自都可信 + 平台可信"之上，宿主/其他 TD 无法伪造他人的 Quote。工程价值在于：让机密 VM 之间能安全地建立互信，支撑分布式机密应用。

单 TD 可信还不够，协作的 TD 需要互信。TD-TD attestation 用可验证 Quote 建立对等信任，边界清晰且不依赖宿主。

• Quote Enclave 的角色
• Quote 生成流程（TDREPORT → Quote）
• 远程证明的可信链

在 TDX 中，TD 先通过 TDCALL 生成 TDREPORT（由 TDX Module 签名，报告 TD 的度量与平台信息），随后由平台上的 Quote Enclave（一个独立的、可信的 SGX enclave 或类似组件）将 TDREPORT 转换为可被远程验证方理解的 Quote（内含平台签名、证书链等）。Quote 由代表平台密钥的签名，验证方通过 Quote 的证书链验证平台可信，再比对 TDREPORT 中的度量确认 TD 可信。工程价值在于：把"TD 内部度量"与"平台身份证明"分离，形成 TDX Module → Quote Enclave → 远程验证方的完整可信链，让验证方无需接触 TD 也能确认其机密环境可信。

Quote 是"平台对 TD 的担保"。Quote Enclave 负责把硬件度量包装成可验证的签名声明，是远程证明从硬件到网络验证的桥梁。

• TDX 版本演进对 attestation 的影响
• 兼容性（quote 格式、度量、接口）的处理
• 前后版本迁移的工程挑战

TDX 1.5 与 2.0 在 attestation 的度量内容、Quote 格式、TDREPORT 字段与接口上有演进（如 2.0 支持更多 TD 特性、新的度量项）。工程边界在于：新版本 TDX Module 需要保持对旧版本生成的 Quote 与证明流程的兼容性，使验证方（verifier）能同时验证不同版本 TD 的 Quote；同时验证方需感知版本差异以正确解析字段与安全属性。工程价值在于：版本兼容让云平台在升级 TDX 时不会破坏已有租户的证明链路，实现平滑演进，避免"版本升级即信任断裂"。

证明生态的兼容性决定能否平滑升级。TDX 需在增强能力的同时保持 Quote 可验证性，避免破坏既有验证方的信任。

• Kata 3.x 的架构（rootfs、image、shim）
• 与机密 VM 的协同（镜像解密、rootfs 可信）
• 机密容器的完整启动链

Kata Containers 3.x 使用"轻量虚机 + 内核"运行容器，其中 rootfs 与容器镜像加载在 Guest VM 内完成。与 TDX/SEV-SNP 协同时：镜像 pull 后由 initramfs/rootfs 在机密 VM 内接收，镜像内容在 VM 内被解密/校验（配合 CoCo 的镜像加密与签名），rootfs 与内核在可信范围内加载，避免宿主看到容器内容。shim（如 kata-runtime shim）负责把 containerd 的容器请求翻译成机密 VM 的启动与监控。工程价值在于：构建了从镜像拉取到 VM 启动再到容器运行的完整可信链，让机密容器在 Kata 上即以硬件 TEE 保护启动与运行。

机密容器的成败在"启动链是否全程可信"。Kata 3 把 rootfs/image 加载放进机密 VM，并用 shim 衔接，保证容器内容不落宿主明文。

• Secret Network 的机密智能合约概念
• SGX enclave 保护区块链节点状态
• encrypted state 的意义

Secret Network 是一个基于 Cosmos SDK 的机密智能合约区块链，其节点运行在 SGX enclave 中，使智能合约的输入、输出与状态（encrypted state）在链上保持机密，同时仍可验证。节点把合约执行与状态存储放在 enclave 内，状态以加密形式持久化，只有持有正确密钥的 enclave 能解密，外部（包括其他节点与验证者）只能看到明文之前的加密数据。工程价值在于：让"可验证 + 可加密"并存——DeFi 等场景需要透明度又需要隐私，Secret Network 用 SGX 在保持链上可验证性的同时提供数据机密性。

区块链天然公开，隐私需求则要机密。SGX enclave 把执行与状态藏进可信硬件，既保证计算的正确性（可验证）又保护数据（机密）。

• containerd snapshotter 的作用
• Kata 3 在镜像拉取/解包中的特殊处理
• 与机密镜像解密的协同

containerd 的 snapshotter 负责把容器镜像解包成可挂载的文件系统层（snapshot）。Kata 3 在机密计算场景下定义/使用特殊的 snapshotter（如 CoCo 的 guest pull snapshotter 或 encrypted image snapshotter），把镜像层以加密形式处理，并允许在机密 VM 内完成镜像拉取与解包（guest pull），而不是在宿主侧明文解包。工程边界在于：普通镜像在宿主由 snapshotter 解包，但机密镜像的解包/解密要么在 guest VM 内进行（guest pull），要么在宿主侧用加密 snapshotter 配合密钥管理，保证明文的容器层不落在宿主磁盘。工程价值在于：让机密容器的镜像管理融入 containerd 标准流程，同时保持镜像内容的机密性。

镜像层若在宿主明文解包则机密性尽失。Kata 3 用 snapshotter 把解包/解密移到 guest 或加密处理，是"标准 containerd 接口 + 机密语义"的组合。

• 三种 TEE 的架构与信任模型
• 各自的内存加密与隔离机制
• 生态与适用场景差异

Intel TDX 基于 VMX 虚拟化扩展，在 SEAM 模式运行 TDX Module，通过 MKTME 对 TD 内存加密，提供 TD 与 TD、TD 与宿主间的隔离，信任根在 TDX Module 与平台。AMD SEV-SNP 基于 SEV 内存加密，配合 RMP 提供完整性保护与页面状态机，把 VM 的加密与防篡改交给硬件，支持多密钥与迁移。ARM CCA 引入独立的 Realm 世界，由 RMM（Root World 固件）管理 Realm，替代传统 hypervisor 来管理机密内存。三者共同点：都基于硬件内存加密 + 远程证明 + 最小可信基（TCB）；差异点：TEE 管理机构不同（Intel 的 SEAM/TDX Module、AMD 的 RMP/SEV、ARM 的 RMM/Realm），生态与指令集各异，且 Intel/AMD 面向 x86 服务器，ARM CCA 面向 ARM 服务器（含多厂商）。工程价值在于：为企业提供多路线选择，按平台与生态取舍。

三条路线是"硬件 TEE 的三种实现"，核心都是"加密 + 隔离 + 证明"。选型取决于平台、生态支持与迁移成本。

• Quote 的生成流程（TEE → 签名 → 证书链）
• 验证方如何验证 Quote
• 度量与平台身份在可信链中的角色

远程证明的可信链为：TEE（TDX/SGX/SEV-SNP/CCA）先对运行环境进行度量（如 TDREPORT、REPORT、Attestation Report），生成包含度量的报告；随后由带平台私钥的签名组件（如 Quote Enclave、平台处理器）将其签名为 Quote，并附上证书链（从平台根密钥到 Quote 签名密钥）。验证方收到 Quote 后：先验证签名与证书链以确认"平台可信"，再比对报告中的度量值与参考值以确认"载体可信"，二者都通过才判定证明成立。工程价值在于：可信链把"平台身份"与"运行内容"绑定，形成可验证、可审计的信任传递，是机密计算与用户建立信任的基石。

证明的成立 = 平台可信（签名链）+ 内容可信（度量）。两者缺一不可，分开验证使逻辑清晰、可审计。