一个号称“不信任云平台”的机密虚拟机，最后栽在云平台能控制的启动链上。
Fabricked 的反常点很直接：攻击者不需要进入受害 CVM，不需要物理接触机器，也不是低权限远程打洞。前提很高——控制 UEFI 和 Hypervisor。可问题也正在这里：SEV-SNP 的威胁模型，本来就是要把云平台级攻击者挡在租户内存外。
AMD 已确认该问题，编号 CVE-2025-54510，并发布公告与固件修复。对普通非机密 VM 用户，它不是新增风险。对正在使用或评估 AMD EPYC SEV-SNP 的企业安全团队，它值得立刻进风险清单。
Fabricked 做了什么：让 RMP 账本没写好，却显示初始化成功
SEV-SNP 的核心机制之一是 RMP。可以把它理解成一份内存页归属账本：哪些页属于机密虚拟机，谁能访问，靠它来管。
正常流程里，AMD PSP 这个安全协处理器会在初始化时写入 RMP。Fabricked 的攻击路径，是让这一步“看起来完成了”，但关键写入没有落到正确的 DRAM 位置。
| 项目 | 关键信息 |
|---|---|
| 攻击目标 | AMD SEV-SNP 机密虚拟机机制 |
| 攻击条件 | 需要 UEFI 与 Hypervisor 权限；不需要物理接触 |
| 攻击路径 | 误配置 AMD Infinity Fabric，误路由 PSP 到 DRAM 的写入 |
| 直接后果 | RMP 保持恶意默认状态，SEV-SNP 误以为初始化成功 |
| 攻击性质 | 论文称为软件攻击，确定性成功，不依赖受害 CVM 内代码 |
| 已确认影响 | 研究者确认 Zen 5 EPYC |
| 范围判断 | 结合 AMD 修复列表，研究者推测 Zen 3/Zen 4/Zen 5 相关平台可能受影响 |
| 修复状态 | AMD 已确认 CVE-2025-54510，并发布固件缓解/修复 |
| 不适用对象 | 不直接适用于 Intel TDX 或 Arm CCA |
攻击步骤并不神秘。
恶意 UEFI 先跳过 Infinity Fabric 的锁定。随后，恶意 Hypervisor 改路由。等 PSP 去写 RMP 时，写入被引到错误位置。系统却仍收到“初始化成功”的结果。
账本没建好，门禁就形同虚设。
CVM 启动后，Hypervisor 可绕过 RMP 的访问控制，对机密虚拟机内存进行任意读写。注意，这里的攻击者不是普通租户，也不是互联网随机攻击者，而是已经拿到平台级控制权的一方。
边界必须说清。
它不改变普通非机密 VM 的传统威胁模型。普通 VM 本来就把 Hypervisor 和平台固件视为可信。它也不能外推成“Intel TDX、Arm CCA 一起被打穿”。目前材料指向的是 AMD EPYC SEV-SNP 相关实现和固件状态。
真正的矛盾：SEV-SNP 要防云平台，却依赖云平台初始化
Fabricked 最扎眼的地方，不是技巧有多漂亮，而是它打在承诺的缝上。
SEV-SNP 的卖点是：租户不必完全信任云服务商，也能把敏感计算放进云上跑。听起来很硬。问题是，机器从上电到 CVM 启动，中间有一条长长的初始化链。
Infinity Fabric 怎么锁。PSP 的写入怎么抵达 DRAM。RMP 是否真的完成初始化。远程证明能不能覆盖足够的平台状态。
这些都不是一句“硬件隔离”能抹掉的细节。
“天下熙熙，皆为利来。”放到云计算里，就是规模、兼容、定制固件、快速上线平台这些现实目标。云厂商需要运营效率。租户需要平台在被运营方控制时，也不能窥探自己的内存。
机密计算想调和这两件事。Fabricked 说明，调和点不只在 CPU 指令集里，也在 BIOS/UEFI、固件更新、平台配置锁定和远程证明策略里。
我不太买账的是一种过度简化的说法：既然攻击需要 UEFI 和 Hypervisor 权限，那就“不算大事”。
门槛确实高。但 SEV-SNP 卖的正是“云平台也不能随便看”的能力。如果威胁模型里包含云平台级对手，那启动链就不能只靠“平台会正确初始化”来兜底。
这也是为什么 Fabricked 不只是一个 AMD 漏洞新闻。它把机密计算的现实成本摊开了：安全承诺越往硬件深处写，治理链条反而越长。
有点像早期铁路和电力网络。不完全一样，但结构相似。真正决定可靠性的，后来不只是机车或发电机，而是标准、维护、巡检、责任边界。机密计算也一样，硅片只是中心部件，不是全部答案。
企业该怎么做：别恐慌，但要把平台状态问到底
最该行动的是两类人。
一类是已经在 AMD EPYC 上使用 SEV-SNP 的团队。另一类是正在评估机密计算、准备把敏感工作负载迁到云上的安全和基础设施团队。
动作要落到清单上，而不是停在“关注漏洞”。
| 对象 | 现在该做什么 | 现实限制 |
|---|---|---|
| 已使用 SEV-SNP 的企业 | 向云厂商确认相关平台是否在 AMD 修复范围内，固件是否已更新 | 租户通常看不到完整 UEFI/固件细节，只能依赖云厂商披露和证明链 |
| 正在评估 SEV-SNP 的团队 | 在采购或上线前加入 Fabricked 风险项，必要时延后生产迁移 | 延后会带来项目成本，但比把威胁模型写空更便宜 |
| 安全架构团队 | 检查远程证明是否能反映足够的平台状态，而不只是确认“启用了 SEV-SNP” | 证明链能覆盖什么，取决于厂商实现和可验证字段 |
| 云服务采购方 | 要求供应商说明固件更新节奏、受影响平台范围、租户侧可验证方式 | 如果供应商只给泛泛承诺，风险仍留在租户侧 |
这里最现实的变化，是采购和上线节奏。
如果你的敏感业务强依赖“云平台不可读内存”这个前提，SEV-SNP 仍然可以评估，但不要只看宣传页。要看固件修复是否完成，看远程证明能证明到哪一层，看云厂商是否愿意把平台状态讲清楚。
如果供应商无法说明这些问题，团队就该观望，或者把迁移拆小。先放低敏感度工作负载，再逐步扩大。安全不是喊口号，安全是把失败路径提前写进流程。
对普通云 VM 用户，这件事不需要制造焦虑。普通 VM 的旧模型里，Hypervisor 本来就是可信方。Fabricked 刺中的，是机密计算的新承诺：当你说平台也不可信时，你必须证明启动链不会替平台开后门。
接下来真正要看的，不是论文标题还能不能再吓人一点，而是三件事：云厂商固件更新是否完成；租户能否验证平台状态；AMD 后续是否把相关初始化锁定做得更难被平台链路误配。
安全行业喜欢把漏洞讲成武侠故事：某个绕过多精巧，某个技巧多漂亮。Fabricked 更像一笔账。
你买到的不是一条 CPU 特性。你买的是初始化、锁定、证明、更新、运营这一整条链。
链条里只要有一环默认“别人会好好做”，攻击者就会从那里进来。