2.3 AMD SEV与机密虚拟机
2.3 AMD SEV 与机密虚拟机
本节摘要：AMD SEV（Secure Encrypted Virtualization）把 TEE 的隔离粒度做到了虚拟机级别——整个 VM 的内存被透明加密，连 Hypervisor 和宿主机都读不到。这种"整机加密"让现有应用几乎不用改就能跑在机密环境里，特别契合公有云的整机迁移场景。本节讲清 SEV / SEV-ES / SEV-SNP 三代技术的演进、为什么它假设"云平台本身可能恶意"、以及它和 SGX 的取舍。
学习目标
阅读完本节，你应当能够：
- 说出 SEV 三代技术各自加了什么能力
- 解释 VM 级内存加密为什么对现有应用友好
- 对比 SEV 与 SGX 的隔离粒度和适用场景
- 说明 SEV-SNP 的反向页表（RMP）怎么防重放攻击
- 判断机密虚拟机（Confidential VM）适合什么业务
问题与直觉
SGX 解决了"应用级"的机密计算，但它有个硬伤：应用必须拆分成可信/不可信两部分，改造工作量大。现实中很多企业想上云的是整个数据库、整个 ERP 系统——这种"整机"负载，让用户为了上机密计算而把整个应用拆成飞地模式，几乎不现实。
AMD SEV 就是冲着这个缺口来的。它的思路简单粗暴：别拆应用了，把整个虚拟机的内存都加密。Hypervisor 负责调度 VM，但看不到 VM 里面跑的是什么；宿主机的管理员能控制物理机，但 dump 内存看到的也是密文。对 VM 内部的应用来说，它根本感觉不到自己在加密环境里——现有代码原封不动跑就行。
这个设计哲学契合公有云的真实痛点：客户想把整个业务系统搬上云，但又不想让云平台看到任何数据。SEV 让"整机上云、数据主权在我"成为可能。微软 Azure 的 Confidential VM、Google Cloud 的 Confidential Computing 都支持 SEV-SNP，就是这个原因。
核心原理
2.1 SEV 三代演进
SEV 不是一蹴而就的，它经历了三代演进，每一代都在补上一代的漏洞：
| 代次 | 全称 | 加的能力 | 防什么 |
|---|---|---|---|
| SEV | Secure Encrypted Virtualization | VM 内存加密 | Hypervisor / 宿主读取 |
| SEV-ES | SEV Encrypted State | CPU 寄存器状态加密 | Hypervisor 窥探 VM 切换时的寄存器 |
| SEV-SNP | SEV Secure Nested Paging | 完整性保护 + 反向页表 | 重放攻击、非法内存映射 |
第一代 SEV 只做机密性——给每个 VM 分配一个唯一的 AES 密钥，VM 内存写入 DRAM 前加密、读取时解密。这挡住了 Hypervisor 和宿主机直接读 VM 内存。但很快发现：Hypervisor 在 VM 切换时会保存/恢复 CPU 寄存器，这个过程里寄存器是明文的，能被窥探。
第二代 SEV-ES 补上了这个漏洞：VM 运行时的 CPU 寱存器状态也加密保存，Hypervisor 看不到寄存器内容。
第三代 SEV-SNP 是最关键的升级。前两代只做机密性（防读），不做完整性（防改）。这意味着 Hypervisor 虽然读不到 VM 数据，但理论上可以偷偷改 VM 的内存映射——把 VM 的某个内存页重定向到别处，或者重放旧的加密页。SEV-SNP 引入了反向页表（Reverse Map Table，RMP） 和完整性保护，挡住了这类篡改和重放。
💡 关键直觉：从 SEV 到 SEV-SNP 的演进，本质是从"只防读"到"又防读又防改"的闭环。这正好印证了第 1 章讲的——机密性和完整性必须协同，只做机密性会被重放攻击绕过。AMD 花了三代才把这个闭环补齐，足见完整性保护的工程难度。
2.2 VM 级加密为什么对应用友好
SEV 最大的工程优势是对现有应用透明。原理在于加密发生在内存控制器层，对 VM 内部的操作系统和应用完全不可见：
- VM 自己的操作系统照常管理页表、分配内存，感觉不到加密。
- 应用代码原封不动编译运行，不需要拆分、不需要特殊 SDK。
- 整个 VM 的内存（包括内核、用户态、缓存）都在加密保护下。
这和 SGX 形成鲜明对比。SGX 要求应用主动创建飞地、用 ECALL/OCALL 拆分逻辑；SEV 只要在 Hypervisor 配置里把 VM 标记为加密实例，VM 内部什么也不用改。对一个想把整套数据库搬上云的金融客户，这个差别决定了"能落地"还是"永远停在 POC"。
2.3 反向页表：SEV-SNP 的核心创新
SEV-SNP 怎么防篡改和重放？核心是反向页表（RMP）。
传统的虚拟化里，Hypervisor 维护一张页表，把 VM 的"客户物理地址"映射到"宿主机物理地址"。问题是这张表由 Hypervisor 控制——Hypervisor 虽然读不到 VM 内存（加密了），但可以改映射，把 VM 的某个页偷偷指向另一个加密页（可能是旧的、被攻击者控制的版本）。这就是重放攻击的温床。
RMP 反过来：由硬件维护一张"宿主机物理页 → 归属哪个 VM"的反向映射。每次 VM 访问内存，硬件都检查 RMP，确认这个物理页确实属于这个 VM、且权限正确。Hypervisor 改不了 RMP（它是硬件表），所以没法做非法重映射。这就堵住了篡改和重放。
| 攻击手段 | 前代SEV能不能防 | SEV-SNP能不能防 |
|---|---|---|
| 直接读 VM 内存 | 能（加密） | 能 |
| Hypervisor 改页表重定向 | 不能 | 能（RMP） |
| 重放旧加密页 | 不能 | 能（完整性+版本号） |
| 窥探寄存器 | SEV-ES 起能 | 能 |
2.4 SEV 的证明机制
和 SGX 一样，SEV 也支持远程证明，但粒度是 VM 级。SEV-SNP 的证明报告（SNP Report）包含 VM 的当前状态、固件版本、加密密钥的派生信息。验证方通过 AMD 签发的证书链验证报告真实性，确认目标 VM 确实跑在真实的 SEV-SNP 硬件上、且状态未被篡改。
这套机制让云客户可以确信："我部署到云上的那个 VM，确实在 SEV 保护下运行，云平台没法偷看也没法篡改。"这是机密虚拟机的信任基础。
工程实践要点
3.1 SEV vs SGX：怎么选
两者都是机密计算的主流方案，但取舍点完全不同：
| 维度 | SEV / SEV-SNP | SGX |
|---|---|---|
| 隔离粒度 | 整个 VM | 单个应用飞地 |
| 应用改造 | 几乎不用改 | 必须拆分可信/不可信 |
| 内存上限 | TB 级（VM 大小） | 几百 MB（EPC） |
| 适合负载 | 数据库、ERP、整机系统 | 隐私查询、密钥运算、轻量计算 |
| 侧信道风险 | 有，但相对少（VM 间隔离强） | 频发（历史重灾区） |
| 部署形态 | Confidential VM | Enclave as a Service |
简单记：整机迁移、重负载选 SEV；细粒度隔离、轻量敏感计算选 SGX。很多公有云现在两者都支持，按负载特性挑。
3.2 机密虚拟机的真实场景
几个 SEV-SNP 已经落地的典型场景：
- 金融风控联合建模：多家银行把各自交易数据放在自己的 SEV VM 里，模型在加密 VM 内训练，谁也看不到对方的原始数据。
- 医疗基因组分析：医院把患者基因数据放进 Confidential VM 上云分析，云平台无法窥探个体隐私。
- 政府身份数据库：公民身份数据部署在第三方云，通过远程证明确保查询逻辑合规、无后门。
这些场景的共同点是：数据敏感、负载是整机形态、对云平台信任度低。SEV 的"整机加密+不用改应用"特性让它们终于能上云。
3.3 SEV 的局限和坑
SEV 不是没代价。几个要留意的点：
第一，性能开销。内存加密/解密在内存控制器层发生，对吞吐量高的应用（大数据库扫描、大模型推理）有 5%-15% 的性能折损。评估时要算进去。
第二，依赖 Hypervisor 正确配置。虽然 SEV 假设 Hypervisor 不可信，但 Hypervisor 得正确发起加密 VM 的创建和密钥协商。配置错误（比如忘记启用加密、密钥管理出问题）会让保护形同虚设。
第三，侧信道并非完全没有。VM 之间的隔离比 SGX 飞地之间强，但共享 CPU 微架构资源时仍有泄露通道。对极高安全要求的场景，还得做额外加固。
⚠️ 常见坑：很多人以为上了 SEV-SNP 就万事大吉，忘了 VM 内部的操作系统和应用本身的安全。如果应用有 SQL 注入漏洞，攻击者从 VM 内部就能偷数据，根本不需要突破 SEV。SEV 保护的是"使用中数据"的内存机密性，不替代应用层安全。
3.4 Intel TDX：SEV 的对位方案
值得一提的是 Intel 也在推对位技术 TDX（Trust Domain Extensions），思路和 SEV-SNP 类似——VM 级内存加密 + 完整性保护，让现有应用不用改就能跑在机密环境。现在的公有云机密计算实例往往同时提供 AMD SEV-SNP 和 Intel TDX 两种选择，工程上选哪个主要看云厂商的硬件供应和你的偏好。两者的概念模型高度相似，理解了 SEV-SNP 就基本理解了 TDX。
本节要点回顾
- SEV 把隔离粒度做到虚拟机级别：整个 VM 内存透明加密，对应用完全不可见，现有代码不用改就能跑。
- 三代演进从"只防读"到"又防读又防改"：SEV 加内存加密，SEV-ES 加寄存器加密，SEV-SNP 加完整性保护和反向页表。
- 反向页表（RMP）是 SEV-SNP 防篡改的核心：硬件维护"物理页归属"映射，Hypervisor 改不了，堵住重定向和重放。
- SEV 适合整机迁移、重负载：数据库、ERP、政府系统这类"整机上云、不想让云看到"的场景是它的主场。
- SEV vs SGX 的核心取舍是粒度和改造成本：SEV 粒度粗但不用改应用，SGX 粒度细但要拆分逻辑。
- Intel TDX 是 SEV-SNP 的对位方案，概念相似，公有云通常两者都支持。
第 2 章把三大架构摆在一起比较完了。下一章钻进这些架构之上的软件栈——不管底层是哪种 TEE，可信 OS、可信应用、世界切换接口的编程模型都有共性，那是开发 TEE 应用的真正战场。
机密虚拟机的信任边界迁移
图：SEV 家族的隔离粒度演进
机密虚拟机路线的最大工程红利是"无需改造应用"：整个虚拟机成为安全边界，普通的数据库、密钥服务、老应用直接开机即获得加密保护——这与 SGX 需要拆分应用做飞地化改造形成鲜明对比。代价是信任边界变粗：边界内任何一个组件的漏洞（内核、驱动、运行库）都在保护圈内，攻击面比进程级飞地大得多。粒度选择因此成为经典权衡：改造成本高、边界内容可控选机密虚拟机；防护面要求极致、愿意做工程改造选进程级飞地。
迁移决策：什么负载值得入驻机密虚拟机
机密虚拟机的"整机入驻"便利也带来一个反向问题：是不是所有负载都该放进去？给一个迁移决策框架，按三步筛。第一步筛数据敏感度：负载处理的数据如果泄露会造成实质伤害（用户隐私、商业机钥、受监管数据），进入候选；处理公开数据的负载入驻纯属浪费溢价。第二步筛信任边界需求：负载是否真的不信任宿主环境？如果企业与云之间已有强合规约束和审计安排，普通虚拟机可能已经够用；机密虚拟机解决的是"法律信任之外还想加技术信任"的场景。第三步筛证明需求：业务是否需要向第三方（监管、合作方）证明处理环境未被篡改？需要则远程证明能力是刚需。三步筛完还留下的负载，入驻的溢价才有正当性。实践中典型的入驻名单：密钥管理服务、隐私计算节点、受监管的数据库、区块链签名节点——清一色的"小而贵"负载，这与第 4 章"保险柜不是体育馆"的原则遥相呼应。