【操作系统百科】机密计算

传统虚拟化里，Guest 信任 Host：Hypervisor 能读 Guest 内存、篡改页表、伪造设备。云场景下这个假设不成立——运维人员、云厂商管理员、被入侵的 Host 都是现实威胁。KVM 架构 篇讨论的 VM-exit 与内存管理，在机密计算里要加上一层：硬件保证 Guest 内存与 CPU 状态对 Host 不可读、不可篡改。

机密计算（Confidential Computing）不是单一技术，而是一组 TEE（Trusted Execution Environment，可信执行环境） 硬件与配套软件栈。本文回答三个工程问题：

1. 威胁模型：TEE 防谁、不防谁？
2. 技术分叉：SGX（进程级 Enclave）、SEV-SNP/TDX（VM 级）、ARM CCA（Realm）各解决什么？
3. 与现有隔离的关系：TEE 是 容器隔离 的下一层，还是替代？

flowchart TD
    subgraph traditional [传统虚拟化信任模型]
        G1[Guest OS / 应用] -->|信任| H1[Host / Hypervisor]
        H1 -->|可读可改| MEM1[Guest 物理内存]
    end

    subgraph cc [机密计算信任模型]
        G2[Guest OS / Enclave] -->|不信任| H2[Host / Hypervisor]
        HW[硬件内存加密 + 完整性] -->|保护| MEM2[Guest 内存]
        G2 --> ATT[远程认证 Attestation]
        ATT --> VER[验证方]
    end

    classDef trusted fill:#3fb95022,stroke:#3fb950,color:#adbac7;
    classDef untrusted fill:#f8514922,stroke:#f85149,color:#adbac7;
    classDef hw fill:#388bfd22,stroke:#388bfd,color:#adbac7;
    class G1,G2,ATT,VER trusted
    class H1,H2 untrusted
    class HW,MEM2 hw

上图的核心信息：机密计算反转了信任方向。Guest 不再假设 Host 善意；硬件与固件提供密码学边界，远程认证让工作负载的调用方确认”跑的是预期代码”。

一、威胁模型：保护边界与已知盲区

1.1 机密计算要防什么

Confidential Computing Consortium（CCC）将机密计算定义为：在使用中（data in use）保护数据的计算技术，依托硬件 TEE 隔离计算与内存。典型威胁包括：

对照 零信任数据安全 的”永不信任，持续验证”：机密计算把验证落到硬件度量（measurement）与 密钥管理 链上，而不是仅靠网络策略。

1.2 TEE 不保证什么

工程上必须写清的边界：

• I/O 路径：磁盘、网络、GPU 数据通常经 Host 转发；明文可能在 bounce buffer 或 virtio 队列中暴露，除非额外加密（virtio-crypto、TDX Connect 等）。
• 侧信道：TEE 不自动消除 Spectre 类或缓存侧信道；SGX 历史上有多起侧信道披露，需软件与微码缓解。
• 供应链：远程认证只证明”当前运行的代码度量”，不证明应用逻辑无后门；镜像构建、CI/CD 仍是信任根。
• 可用性：Host 仍可拒绝调度、掐断网络——机密计算保机密性与完整性，不保可用性（Denial of Service 仍可能）。
• Operator 可见性：调试、崩溃转储、性能剖析在机密 VM 上受限；运维工具链要重做。

1.3 与容器、虚机威胁模型对照

结论：TEE 不是容器隔离的替代品，而是当威胁模型包含”不信任基础设施运营方”时的下一层。容器仍负责密度与快速交付；机密 VM 负责数据在使用中的保护。

二、Intel SGX：进程级 Enclave 与产品边界

2.1 架构要素

Intel Software Guard Extensions（SGX）在 2015 年（Skylake） 随服务器 Xeon 引入，在进程地址空间内划出 Enclave 区域：

• EPC（Enclave Page Cache）：受保护的物理页池，Host 无法直接读取明文。
• EPCM（Enclave Page Cache Map）：记录每 EPC 页的归属 Enclave、权限；CPU 在地址翻译时强制检查。
• Enclave 指令：EADD、EINIT、EENTER、EEXIT 等，由 CPU 微码与 OS 驱动（intel_sgx）协作。

Enclave 代码通过 EENTER 进入，在 CPU 强制隔离下运行；离开 Enclave 时状态加密，防止 Host 从寄存器或内存残留推断秘密。

sequenceDiagram
    participant App as 应用程序
    participant OS as Linux 内核
    participant DRV as intel_sgx 驱动
    participant CPU as CPU SGX 微码
    participant ENC as Enclave

    App->>DRV: ioctl 创建 Enclave
    DRV->>CPU: EADD / EINIT
    App->>CPU: EENTER
    CPU->>ENC: 切换到 Enclave 上下文
    ENC->>ENC: 处理秘密数据
    ENC->>CPU: EEXIT
    CPU->>App: 返回，寄存器状态清除

2.2 远程认证：DCAP 与 EPID

调用方如何确认 Enclave 跑的是预期代码？本地认证（Local Attestation） 在同一平台 Enclave 间用 ECDH 建立信任；远程认证（Remote Attestation） 需要 Intel 或自建 PKI。

• EPID（Enhanced Privacy ID）：早期方案，依赖 Intel 签名服务；隐私性好，运维复杂。
• DCAP（Data Center Attestation Primitives）：数据中心常用，用 PDH（Provisioning Certification Key） 与 QE（Quoting Enclave） 生成可由用户 PKI 验证的 Quote；不强制回连 Intel 在线服务。

软件栈典型路径：应用 Enclave → Quoting Enclave → Quote（含 MRENCLAVE、MRSIGNER 等度量）→ 验证方对照 Collateral（TCB 版本、撤销列表）验签。

2.3 已弃用与版本边界（必读）

SGX 的产品可用性与安全公告必须分开读：

工程含义：新项目若目标通用云 VM，应优先评估 SEV-SNP / TDX，而非绑定 SGX Enclave 编程模型；SGX 仍适用于遗留数据中心 Enclave 应用、特定合规场景，但需核对目标 CPU 是否仍暴露 sgx CPU flag。

# 检查 SGX 是否在 CPU 上启用（输出因机器而异）
grep -E 'sgx|sgx2' /proc/cpuinfo | head -3
# 若为空，则当前主机可能无 SGX 或 BIOS 未开启

2.4 SGX 与 OS 的协作

Linux 内核 drivers/platform/x86/intel_sgx/ 负责：

• 分配 EPC 页（受 BIOS 预留大小限制，常见几十到一百多 MB）
• 处理 #PF 当 Enclave 页换出（EPC 不足时 Enclave Paging 极慢，是已知痛点）
• 暴露 /dev/sgx_enclave、/dev/sgx_provision

用户态：Intel SGX SDK、Open Enclave SDK、Gramine（库 OS，见后文）将 Enclave 生命周期封装为普通进程可加载的库。

2.5 SGX 的定位小结

SGX 是细粒度、进程内 TEE：适合”密钥派生、小计算、远程认证桩”；不适合整虚拟机。与 VM 级方案对比：

2.6 EPCM 与页属性（实现视角）

SGX 地址翻译在常规页表之外查 EPCM：每条记录含 VALID、MODE（Regular/SECS/TCS）、EADDPAGE 所属 Enclave 标识等。CPU 在 Enclave 访问时若 EPCM 与页属性不一致，触发 #GP 或 Enclave 专用异常。

对 OS 开发者的含义：

• EPC 是有限池：sgx_driver 与 BIOS 预留决定上限；大堆 Enclave 会触发换页，延迟陡增
• 不能 swap 到磁盘明文：换出页必须以加密形式存于 EPC 或受控缓冲区
• mmap 语义受限：mprotect 与 fork 对 Enclave 页有特殊规则

这与 Linux 页表与缺页 路径交互，但 Enclave 页走独立 fault 处理（arch/x86/kernel/sgx.c）。

2.7 开源与闭源栈对照

选型除技术外，还需考虑 SDK 维护状态 与 目标硬件族 是否仍被厂商积极支持。

2.8 与虚拟化的嵌套

SGX 与虚拟化：早期 SGX 在虚拟化下受限；数据中心路径转向 TDX/SEV-SNP 机密 VM 而非 Nested SGX。若规划 L1 KVM + L2 机密 Guest，查厂商 嵌套机密 支持矩阵（版本敏感，以文档为准）。

2.9 Quote 验证伪代码（逻辑说明）

以下为 逻辑流程，非可运行代码：

receive(quote, nonce)
verify_certificate_chain(quote.cert_chain, vendor_root_ca)
assert quote.nonce == nonce
assert quote.tcb_status not in REVOKED_LIST
match_reference_values(quote.measurements, policy.allowed_measurements)
return ALLOW or DENY

生产应使用 Keylime、go-tpm、云 attestation SDK，勿手写密码学。

三、AMD SEV 家族：从内存加密到 SNP 完整性

3.1 SEV（Secure Encrypted Virtualization）

AMD 在 EPYC（Zen 1） 引入 SEV：每个 VM 有独立 ASID（Address Space ID） 与内存加密密钥，Hypervisor 读物理内存得到密文。Host 仍控制页表（Nested Page Tables，NPT），理论上可实施 replay 或 alias 攻击。

KVM 集成路径：QEMU 通过 memory-encryption 属性、sev 对象启动 Guest；/dev/sev 接口由 psp-sev 驱动与 AMD PSP（Platform Security Processor） 通信派生密钥。

3.2 SEV-ES（Encrypted State）

SEV-ES 加密 vCPU 寄存器：在 VM-exit 时，Host 无法看到 Guest 通用寄存器明文。这对防止 Host 从 VM-exit 状态推断 Guest 行为至关重要，是对照 VM-Exit 开销 时必须计入的额外成本——部分退出路径需调用 GHCB（Guest-Hypervisor Communication Block） 明文协商。

3.3 SEV-SNP（Secure Nested Paging）

SEV-SNP（Zen 3+ EPYC）在 SEV-ES 基础上增加 内存完整性：

• RMP（Reverse Map Table）：每物理页一条记录，标明归属 VM 与页类型；非法映射触发 #VMEXIT 或致命错误。
• VMPL（VM Permission Level）：类似 ring，0–3 级；Guest 内核通常在 VMPL0，部分安全模块（如 SVSM）可运行在更高特权。
• 禁止 Host 写入已归属 Guest 的页：缓解 remap、double-mapping。

flowchart LR
    subgraph guest [Guest VM]
        GK[Guest Kernel VMPL0]
        GS[Guest 安全模块 VMPL1]
    end
    subgraph amd [AMD 硬件]
        NPT[NPT 页表]
        RMP[RMP 完整性表]
        ME[AES-128 内存加密]
    end
    subgraph host [不可信 Host]
        HV[Hypervisor KVM/QEMU]
    end
    GK --> NPT
    HV -->|无法篡改映射| RMP
    NPT --> ME
    HV -.->|仅见密文| ME

3.4 启动与策略

QEMU 启动 SEV-SNP Guest 的典型参数（版本随 QEMU 演进，以下摘自 AMD 与 QEMU 文档示例）：

qemu-system-x86_64 \
    -machine q35,confidential-guest-support=sev0 \
    -object sev-snp-guest,id=sev0,cbitpos=51,reduced-phys-bits=1 \
    -cpu EPYC-v4 \
    -m 4G \
    -enable-kvm

Guest Policy 位控制调试、迁移、单 socket 等能力；生产环境应关闭允许 Host 调试的 policy 位，否则削弱机密性。

用户态工具：

• snpguest：生成报告、与 PSP 交互
• snphost：Host 侧管理

3.5 远程认证（AMD）

AMD 路径与 Intel DCAP 类似但 PKI 独立：

1. Guest 内 AR（Attestation Report） 由 PSP 签名
2. 报告含 Guest 固件、内核、启动度量
3. 验证方通过 AMD 发布的 VCEK（Versioned Chip Endorsement Key） 或 VLEK 链验证

Confidential Containers 与 Kata 等栈将上述报告对接到 Kubernetes attestation admission。

3.6 性能开销（引用数据）

AMD 白皮书 SEV-SNP: Strengthening VM Isolation with Integrity（2020）及后续云厂商文档指出：内存加密对带宽敏感负载有约 个位数到低两位数百分比 的开销，随工作集与是否启用完整性而异。本文未在本地复现 benchmark；若你做容量规划，应在目标实例类型上对代表性负载实测，并区分 AES-NI 卸载与 NUMA 远程访问因素。

四、Intel TDX：Trust Domain 与 SGX 的分工

4.1 设计定位

Intel Trust Domain Extensions（TDX） 在 Sapphire Rapids 一代起作为 VM 级 机密计算推广，与 SGX 的 Enclave 模型互补：

TDX 将 Hypervisor 降级为资源编排者：仍可调度 vCPU，但不能读 TD 内存、不能篡改 TD 页表映射（由 TDX Module 与 CPU 共同强制）。

4.2 关键组件

• SEAM（Secure Arbitration Mode）：CPU 运行 TDX Module 的特权模式，处理 TD 创建、页映射、#VE（Virtualization Exception）。
• TDX Module：Intel 签名的固件模块，实现 TD 生命周期。
• TDCALL / TDEXIT：Guest 与 Module/Hypervisor 的受控接口。
• Quote Generation：通过 TD Report 结构对接远程认证，与 SGX DCAP 生态有整合趋势（Intel Trust Authority 等）。

4.3 与 KVM 的集成

Linux 主线持续合入 TDX 支持：arch/x86/kvm/tdx.c、QEMU 的 confidential-guest-support=tdx0 等。路径与 KVM 架构 中 /dev/kvm + QEMU 设备模型一致，额外在 KVM_RUN 路径处理 TDX 相关 exit。

# 检查内核是否启用 TDX 相关配置（配置名随版本变化）
grep -E 'CONFIG_KVM_INTEL_TDX|CONFIG_INTEL_TDX' /boot/config-$(uname -r) 2>/dev/null || true

4.4 TDX 相对 SGX 的工程优势

• 无需重写为 Enclave：Guest 跑标准 Linux，驱动与容器栈改动小于 SGX。
• 内存规模：受物理内存限制，而非 EPC 几十 MB 上限。
• 云厂商对齐：Azure、GCP、阿里云等 Confidential VM 产品多基于 SEV-SNP 或 TDX。

局限：需要新一代硬件；I/O 虚拟化、实时迁移、嵌套虚拟化能力仍在演进；TDX Connect 等 I/O 保护特性需单独评估版本与设备支持。

五、ARM Confidential Compute Architecture（CCA）

5.1 Realm 与 RMM

ARM CCA（2021 架构公布，Armv9-A）引入 Realm，由 RMM（Realm Management Monitor） 管理，与 TrustZone（安全世界/普通世界）并存：

• Normal World：Host Hypervisor（如 KVM、Hyper-V）
• Secure World：TrustZone TEE（传统移动安全）
• Realm World：机密 VM，硬件隔离内存与完整性，Hypervisor 不可读

flowchart TD
    NW[Normal World<br/>Host + 非机密 VM]
    SW[Secure World<br/>TrustZone TEE]
    RW[Realm World<br/>机密 VM]
    EL3[EL3 固件]
    RMM[RMM]
    EL3 --> RMM
    RMM --> RW
    NW -->|不可读 Realm 内存| RW
    SW -.独立信任根.-> RW

5.2 与 x86 TEE 的对照

ARM 路径对 自研芯片云（AWS Graviton、阿里倚天等）是天然选项；x86 路径在混合云场景仍占多数。应用开发者应把”目标云实例族 + 认证 API”作为选型第一维，而非先选编程模型。

六、远程认证：信任链与验证实践

6.1 度量什么

启动链通常度量：

1. 固件（OVMF/ACPI TDVF 机密变体）
2. Bootloader / shim
3. 内核（含 initrd 哈希策略）
4. 策略：是否允许调试、是否绑定特定镜像版本

度量寄存器示例（Intel SGX）：MRENCLAVE（Enclave 代码哈希）、MRSIGNER（签名者）；AMD SNP：REPORT_DATA 可嵌入用户自定义 nonce；TDX：RTMR（Runtime Measurement Register） 扩展。

6.2 验证方做什么

验证方（云客户、合规审计、K8s Admission）执行：

1. 解析 Quote / Attestation Report
2. 验证证书链至芯片厂商 Root CA 或客户配置的 PKI
3. 对照 Reference Values（允许的 MRENCLAVE、内核版本、initrd 哈希）
4. 检查 TCB Status（微码、固件是否已撤销）
5. 绑定 nonce 防重放

这与 零信任持续验证 的”每次访问重新评估”一致，但证据来自硬件而非仅 JWT。

6.3 COCONUT-SVSM 与 Guest 侧安全服务

COCONUT-SVSM（Community SVSM）是 AMD 生态的开源 SVSM（Secure VM Service Module） 实现，运行在 VMPL0，为 Guest 提供：

• 虚拟 TPM（vTPM）
• 密钥封装与密封（sealing）
• 与 PSP 协同的认证辅助

Guest Linux → /dev/sev-guest 或 SVSM 调用 → PSP 硬件

没有 SVSM 时，Guest 仍可通过 sev-guest 驱动获取报告，但完整 vTPM 与密封密钥链可能需额外组件。部署机密 K8s Node 时，需把 SVSM 容器或 initramfs 阶段纳入度量策略。

七、软件栈：从 Hypervisor 到工作负载

7.1 分层视图

flowchart TB
    APP[应用 / 容器镜像]
    RT[运行时 Gramine / Occlum / 普通 libc]
    GUEST[Guest OS 内核]
    FW[OVMF-TDX / AmdSevX64 固件]
    HV[KVM / Hyper-V + QEMU]
    HW[SEV-SNP / TDX / CCA 硬件]

    APP --> RT --> GUEST --> FW --> HV --> HW
    COCO[Confidential Containers] --> APP
    KATA[Kata + 机密 VM] --> GUEST

7.2 Confidential Containers（CoCo）

Confidential Containers（CNCF 沙箱项目）目标：在 Kubernetes 上跑机密 Pod，底层是机密 VM 而非仅 namespace 隔离。

核心组件：

• kata-qemu / kata-qemu-tdx：Kata 运行时启动带内存加密的 QEMU VM
• guest-components：Guest 内 attestation-agent、confidential-data-hub（密钥/密钥代理）
• verifier：集群侧验证 Quote，策略引擎（如 Rego）决定 Pod 是否准入

与 容器隔离 的关系：CoCo 用 VM 替换 runc 的隔离边界，容器镜像与 cgroup 语义保留，但 Linux namespace 隔离升级为硬件 VM。适合”已上 K8s、威胁模型升级”的路径。

7.3 Gramine

Gramine（原 Graphene）是 Library OS：在 SGX Enclave 或机密 VM 内提供精简 POSIX，应用以 未经修改或轻改 的二进制运行：

• PAL（Platform Abstraction Layer）适配 SGX、SEV、TDX
• 远程认证集成 ra-tls（TLS 握手嵌入 Quote）
• 适合数据库、推理服务把现有 Linux 二进制迁入 TEE

代价：系统调用翻译开销、文件系统语义需 chroot 或加密 FS；不是万能容器替代品。

7.4 Occlum

Occlum 面向 Intel SGX 的 LibOS，强调多进程语义模拟与 Rust 实现的安全隔离。在 SGX EPC 受限场景常用 Occlum + 小镜像；若迁移到 VM 级 TEE，Gramine 或原生 Guest 更常见。

7.5 其他组件

八、I/O 与网络：机密 VM 的短板

8.1 问题本质

Guest 磁盘与网络 DMA 最终由 Host 配置。机密性风险点：

• Virtio 队列在 Host 物理内存，若未加密，数据明文可见
• 迁移与快照被 Host 控制
• GPU 直通涉及 IOMMU 与 TEE 交互，仍在标准化

8.2 缓解路径

工程建议：默认假设 网络与块设备在 Host 可见，除非启用端到端加密（TLS、mTLS、密钥管理 托管）或厂商明确的 I/O TEE 特性。

九、AWS Nitro Enclaves 与 VM 级 TEE 的差异

AWS Nitro Enclaves 不是 SEV/TDX 机密 VM，而是 同一 Nitro 主机上的隔离 Enclave VM：

• 无交互式访问、无外部网络（仅 vsock）
• 父 EC2 实例通过 vsock 通信
• 认证使用 Nitro PCR（Platform Configuration Register）

二者解决”不信任云管理员”的类似问题，但可移植性与栈复用不同：Nitro 深绑 AWS；SEV-SNP/TDX 可在混合云迁移镜像（在策略与硬件族匹配前提下）。

十、性能、容量与运维

10.1 开销来源

1. 内存加密带宽：AES-128 引擎占用内存控制器带宽
2. 完整性检查：RMP 查找与 TDX Module 路径
3. VM-exit 放大：SEV-ES GHCB、TDX #VE
4. 认证与密封：启动时 PSP/SEAM 调用
5. 缺少传统调试：strace、/proc 部分信息、crash dump 受限 → 故障排查时间成本

10.2 引用性能结论（非自测）

• AMD 文档：多数通用计算负载 <10% 吞吐下降（加密开启、完整性开启时略高）
• 学术与工业界对 SGX Enclave 分页（EPC 压力）报告显示 数量级延迟 退化——SGX 小 Enclave 与大数据集不匹配
• 云厂商实例规格常标注 CVM 与普通 VM 同 vCPU 定价或溢价——以各厂商当期定价页为准，本文不预测价格

10.3 与 NUMA、调度的交互

机密 VM 仍服从 NUMA 内存 与 CPU 亲和规则。内存加密不消除跨 socket 访问延迟；在 EPYC 多 die 上，Guest 与 Host 的页分配策略共同决定性能。生产上应对机密与非机密负载分别做 numactl 剖析。

10.4 Guest 内观测工具

机密 VM 内仍可使用大部分 Guest 内 观测手段，与 perf 子系统、eBPF 核心 系列衔接：

# Guest 内（非 Host）执行
perf stat -e cycles,instructions ./workload
bpftrace -e 'kprobe:do_sys_open { @[comm] = count(); }'

Host 侧对 Guest 内存的 perf mem、物理地址采样等会失效或只得到密文意义有限的数据。性能调优应依赖 Guest 内 agent 或 virtio 导出指标，而非传统裸金属 Host 工具。

10.5 容量规划提示

• 为认证代理（attestation-agent）、SVSM 预留 vCPU 与内存（通常数百 MB 级，随栈版本变化）
• EPC 场景（SGX）将 Enclave 堆峰值 与 EPC 预留写进容量模型
• 机密 VM 冷启动常比普通 VM 多 固件与 PSP 握手 秒级；自动伸缩需调大 initialDelaySeconds

十一、与内核安全机制的叠加

机密计算不替代 KASLR 与缓解措施、seccomp 或 能力位。推荐分层：

1. 硬件 TEE：防 Host 读内存
2. Guest 内核缓解：防 Guest 内漏洞
3. 容器/seccomp：防工作负载横向移动
4. 远程认证：防镜像篡改与降级攻击

Rust for Linux 减少 Guest 内核内存漏洞，与 TEE 正交：Rust 不能阻止恶意 Hypervisor，TEE 不能修复 Guest 内核 UAF。

十二、生产部署边界（2026）

诚实边界：

本文不预测哪家云厂商领先；选型应基于工作负载威胁模型、实例族可用性、认证 API 与合规要求。

十三、选型决策框架

13.1 工作负载画像

在画决策树之前，先把工作负载按 数据敏感度 × 形态 × I/O 分类：

13.2 决策流程图

flowchart TD
    START[工作负载上云?] -->|是| THREAT[是否不信任云管理员?]
    START -->|否| ONPREM[自建 SEV/TDX 硬件]
    THREAT -->|否| CONTAINER[容器 + 加固 seccomp/MAC]
    THREAT -->|是| FULL[需要完整 Linux?]
    FULL -->|是| CVM[机密 VM SEV-SNP/TDX/CCA]
    FULL -->|否| ENC[Enclave SGX/Nitro]
    CVM --> K8S{已有 K8s?}
    K8S -->|是| COCO[Confidential Containers]
    K8S -->|否| LIBVIRT[libvirt/QEMU 机密 VM]

具体问题清单：

1. 数据在使用中是否必须对 Host 不可见？（法规、合同）
2. 是否需要完整 VM（systemd、现有 agent）还是单一 Enclave 进程？
3. 认证方是谁（自建 PKI vs 云厂商 API）？
4. I/O 是否可端到端 TLS？GPU 是否必需？
5. 可接受的开销上限与实例族预算？

13.3 侧信道缓解清单（不展开攻击）

TEE 不消除侧信道。工程上常见缓解（非完整列表）：

• 核心隔离：isolcpus、IRQ 亲和，减少与恶意邻居共享物理核（云厂商常提供 CC 专用池）
• 恒定时间密码学：避免密钥相关分支（见 实现陷阱）
• 缓存刷新策略：SGX SDK 与 OpenSSL 部分版本提供 mitigations；跟踪 CVE 与微码
• 最小 Enclave 面积：减少共址代码量，降低泄漏面
• 禁用超线程（部分高敏场景）：视威胁模型与性能权衡

13.4 云产品形态对照（2026，以厂商文档为准）

本文不比较性能或价格；迁移时核对 地域、实例族、认证 API 三要素。

13.5 与可拆分 OS 的衔接

下一篇 可拆分 OS 讨论 CXL 内存池化 与机密计算的交汇：池化内存若跨主机共享，RMP/完整性 与 加密密钥域 如何划分仍是开放工程题。规划数据中心架构时，应同时评估 不信任 Host 与 不信任远程内存控制器 两类威胁。

十四、固件与启动链：OVMF、ACPI 与度量

14.1 为什么固件是信任根的第一环

机密 VM 的远程认证不只度量内核，而是从 Reset Vector 开始。若 OVMF（UEFI）或 ACPI 表被 Host 替换，Guest 可能在恶意固件下启动——SEV-SNP/TDX 通过 固件签名与启动策略 将固件纳入度量。

AMD 路径常见 AmdSevX64.dsc 变体：在标准 OVMF 上增加 SEV 相关 PPI（Platform Initialization）与 Secrets 注入（VMSA、CPUID 掩码）。Intel TDX 使用 TDVF（Trust Domain Virtual Firmware） 规范，定义 TD 可见的固件接口。

sequenceDiagram
    participant HV as Hypervisor
    participant FW as OVMF/TDVF
    participant KERN as Guest 内核
    participant PSP as PSP / TDX Module

    HV->>FW: 加载固件镜像
    FW->>PSP: 请求内存加密上下文
    PSP-->>FW: 密钥材料 / 证明句柄
    FW->>KERN: 跳转，记录 PCR/度量
    KERN->>PSP: 扩展认证报告

14.2 Linux Guest 内核配置要点

主线内核中与 AMD 内存加密相关的选项（名称随版本演进，以 make menuconfig 为准）：

CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_KVM_AMD_SEV=y

TDX Guest 侧需匹配发行版提供的 confidential kernel 或主线 CONFIG_INTEL_TDX_GUEST。initrd 中的模块与内核版本必须纳入认证策略，否则”内核升级后 Pod 被拒”是预期行为。

14.3 initrd 与 cmdline 策略

生产机密 VM 常见约束：

• 只读 rootfs（dm-verity / erofs）+ 度量 verity 根哈希
• 内核 cmdline 绑定：root=UUID=... 与 initrd 内容进入 RTMR/Report
• 禁止单用户模式除非策略允许调试 policy

这与 完整性验证 中的 IMA/EVM 思路一致，但验证方从本地 fs 扩展到远程 attestation verifier。

十五、开发路径：从普通 VM 到机密 VM

15.1 迁移检查表

15.2 Gramine 最小示例（概念路径）

以下不是完整可编译清单，说明 PAL 加载应用 的路径（Gramine 文档 A 级）：

# 构建 Gramine manifest（声明可执行文件、环境、Enclave 大小）
gramine-manifest myapp.manifest myapp.manifest.sgx
gramine-sgx-sign --manifest myapp.manifest.sgx --output myapp.manifest.sgx.signed

# 在 SGX 机器上启动（需 EPC 与 /dev/sgx_enclave）
gramine-sgx myapp

在 机密 VM 上，同一应用常改为：普通动态链接二进制 + 标准 Guest，由 VM 级加密覆盖内存，无需 Enclave 分页；远程认证在 VM 级完成，应用无需链接 libsgx。

15.3 CoCo Pod 部署要素（概念）

Kubernetes 侧典型对象链：

1. RuntimeClass → kata-qemu（机密）
2. Node 标签：node.kubernetes.io/cc-feature 等（随 CoCo 版本）
3. Pod 注解请求机密资源
4. 集群部署 attestation-service 验证 Quote

失败排查顺序：节点硬件 → QEMU 日志 → Guest dmesg | grep -i sev → agent 日志 → verifier 策略 JSON。

十六、合规与审计视角（非法务）

多个法规框架将”加密与访问控制”列为数据保护手段；机密计算提供 使用中加密 的技术证据，但不自动等于合规。审计方通常关注：

• 密钥谁持有（客户持钥 vs 云持钥）
• 认证日志是否不可篡改
• 侧信道风险是否写入风险登记册
• 退出策略（数据销毁、密封密钥失效）

本文不做法律解释；工程上应保留 Quote 验证日志 与 策略版本，便于与 零信任可观测性 关联。

十七、故障模式与限制案例

十八、与虚拟化系列的衔接

回顾 虚拟化基础 与 KVM：

• SEV-ES 改变部分 VM-exit 的寄存器语义，Guest 需 PARAVIRT 或 GHCB 处理
• IOMMU 在机密直通设备时与 RMP 交互，错误配置可导致启动失败
• 嵌套虚拟化（L1 Hypervisor 跑 L2 Guest）在机密模式下常受限或禁用

若你在 L1 已跑 Kubernetes，再在机密 VM 内跑 Pod（CoCo），要核算 双层调度 开销与认证链长度。

十九、术语表

二十、开发者 FAQ

18.1 我还用容器就够了吗？

若威胁模型只有 多租户邻居 与 应用漏洞，容器隔离 + seccomp 通常够。若合规要求 云管理员不可见明文，评估机密 VM 或 Enclave。

18.2 SGX 还要学吗？

维护遗留 Enclave 要；新云原生服务 优先学 机密 VM + CoCo 与远程认证 API，减少 EPC 限制带来的架构债。

18.3 性能是否一定差很多？

引用 AMD/Intel 文档：多数通用负载个位数百分比；I/O 密集且未加密通道 可能暴露明文，与加密开销无关——先修架构。

18.4 与 完整性验证 区别？

IMA/EVM 验证 文件完整性；远程认证验证 运行时度量。二者可串联：构建时签名 + 运行时 Quote 对照同一哈希。

二十一、总结

• 机密计算反转信任模型：Guest 不信任 Hypervisor，硬件提供内存加密与完整性（SEV-SNP RMP、TDX Module、ARM RMM）。
• SGX 是进程级 Enclave，客户端已式微，服务器与 TDX 分工明确；选型前查 CPU 与 BIOS。
• SEV-SNP / TDX / CCA 是云机密 VM 主流，与 KVM 集成成熟度持续提高。
• 远程认证把信任落到度量与 PKI，需与 CI/CD、镜像策略联动。
• Confidential Containers、Gramine、Occlum 解决”如何在 TEE 里跑现有软件”，不是替代 容器隔离，而是升级底层边界。
• I/O 与侧信道仍是主要盲区；默认对网络/磁盘做应用层加密，侧信道跟踪微码与最佳实践。
• 与 Rust 内核、零信任数据安全 叠加使用，各防不同对手。
• 阅读 侧信道攻击入门 理解 TEE 不覆盖的威胁类（本文不展开利用细节）。

参考资料

规范与官方文档（A 级）

• Intel. Intel Software Developer Manual, Volume 3D: SGX, TDX（当前修订版）
• Intel. Trust Domain Extensions (TDX) Module White Paper, 2023
• AMD. SEV-SNP: Strengthening VM Isolation with Integrity, 2020
• AMD. AMD64 Architecture Programmer’s Manual, Volume 2, SEV-ES/SNP 章节
• ARM. Arm Confidential Compute Architecture (RME), DEN0125, 2022 起各修订
• Confidential Computing Consortium. Confidential Computing: A Technical Analysis, v1.0

软件项目与文档（A/B 级）

• Linux Kernel: Documentation/arch/x86/amd-memory-encryption.rst, drivers/crypto/ccp/sev-dev.c
• QEMU: Confidential Guest Support 文档
• CNCF Confidential Containers: confidential-containers.org 架构文档
• Gramine: gramine.readthedocs.io
• Occlum: occlum.io 文档
• COCONUT-SVSM: github.com/coconut-svsm/svsm

论文与书籍（A 级）

• Costan, V., Devadas, S. “Intel SGX Explained.” MIT TR, 2016
• Kaplan, D. et al. “AMD Memory Encryption.” White paper, 2016

本站相关

• 容器隔离的真实强度
• KVM 架构
• VM-Exit 开销
• NUMA 内存
• KASLR 与缓解措施
• Rust for Linux
• 密钥管理
• 零信任数据安全

工具

• snpguest, snphost（AMD 认证）
• tdx-tools, tdx-attest（Intel TDX）
• qemu-system-x86_64 机密 Guest 参数
• keylime, gramine-sgx, occlum

上一篇：Rust for Linux 下一篇：可拆分 OS