在云计算机密计算领域，AMD SEV-SNP（Secure Encrypted Virtualization with Secure Nested Paging）一直被视为保护虚拟机内存完整性与机密性的硬件级基石。然而，ETH Zurich 研究团队在 2026 USENIX Security 会议上公布的 Fabricked 攻击表明，这条防线的边界远比厂商文档描述的更脆弱 —— 攻击者只需利用固件层对 Infinity Fabric 的配置缺陷，即可让安全协处理器（PSP）的初始化流程形同虚设，最终实现对机密虚拟机（CVM）内存的任意读写。理解这一攻击的技术路径，对于在云端依赖 SEV-SNP 的安全架构师而言，已经成为一项必修课题。
攻击的本质：利用互联架构的信任传导
要理解 Fabricked，必须先理解现代 AMD EPYC 处理器的物理架构。当代 Zen 架构处理器采用 chiplet 设计：多个 CPU Core Complex Dies（CCD）通过高速互联总线连接到中央 I/O Die（cIOD），而内存控制器、PCIe 控制器和安全协处理器 PSP 均位于这颗 I/O die 上。连接各组件之间的这条互联总线就是 AMD 的 Infinity Fabric。
Infinity Fabric 承担着三项关键职责：缓存一致性协议、内存地址路由和设备间数据传输。在 SEV-SNP 的威胁模型中，AMD 明确定义了各组件的信任边界 ——UEFI 固件被视为不可信，虚拟机监控器（hypervisor）在某些条件下也不完全可信，唯独 PSP 被认为是硬件级的可信根。问题恰恰出在这里：Infinity Fabric 的初始配置权限被委托给了 UEFI，AMD 认为 UEFI 不可信后可以通过锁定机制来保护路由规则，但实际实现中这个锁定流程存在缺陷。
研究团队发现，恶意 UEFI 可以在初始化阶段跳过某些 Infinity Fabric API 调用，从而让互联结构在 SEV-SNP 激活后仍然保持可配置状态。这意味着攻击者（持有 hypervisor 权限的攻击者）可以在运行时重新修改内存路由策略，而这一切发生时 PSP 毫不知情。
攻击向量详解：从 RMP 初始化失效到内存任意访问
SEV-SNP 的核心数据保护机制依赖于 Reverse Map Table（RMP），这是一张记录每个物理页面对应虚拟机所有权的表格。当 CVM 尝试访问某个内存页时，硬件会查阅 RMP 以验证请求是否合法 —— 如果 VMM 在 RMP 中写入了错误的映射关系，硬件将拒绝访问。然而，这一切成立的前提是 RMP 必须在 SEV-SNP 初始化阶段被 PSP 正确初始化。
在 SNP_INIT 阶段，PSP 负责将 RMP 的所有条目设置为安全的默认值。具体来说，PSP 会向 DRAM 写入大量的初始化数据，覆盖 VMM 预填的任何恶意条目。这一写入过程经过了 Infinity Fabric—— 内存请求从 PSP 出发，经过互联总线，最终到达 DRAM 控制器。
Fabricked 攻击的核心就在于此：攻击者通过修改过的 UEFI 绕过 Infinity Fabric 的锁定机制后，在 SNP_INIT 执行前夕对互联路由规则进行精准篡改。具体操作目标指向 IOMS（Infinity Fabric Input/Output Management Subsystem），通过对 Fabric ID 到目标节点的映射进行重新编程，使得 PSP 发出的某些写操作被悄然丢弃。换言之，PSP 认为数据已经写入 DRAM，而实际上这些写入请求在半路被错误路由吞噬了。
结果是一个精心设计的 RMP 状态：关键页面的 RMP 条目仍然是攻击者预先设置的不安全值，而 PSP 因为没有收到写操作失败的反馈，继续认为初始化成功。当受害者随后在这台主机上启动 CVM 时，VMM 已经拥有了在 RMP 中植入任意映射的能力，从而可以对 CVM 内存执行任意读写，甚至伪造远程证明。
技术根因：两个互锁的设计缺陷
研究团队将 Fabricked 的可行性归结为两个相互依存的硬件级缺陷。第一个缺陷是 Infinity Fabric 路由规则在特定条件下可以被恶意篡改。AMD 的架构设计要求 UEFI 在系统启动时锁定某些 Fabric 配置寄存器，但 UEFI 本身处于威胁模型的不可信区间 ——AMD 的设计假设通过锁定操作来弥补这一点，然而锁定操作本身并非不可绕过。
第二个缺陷更加隐蔽：即使 PSP 发出的内存请求被错误路由导致写操作丢失，互联结构也不会向 PSP 返回错误信号。正常情况下，当一个内存写操作命中错误的目标节点时，Fabric 应该产生错误响应或重试信号；但在当前 AMD Zen 架构的实现中，当 IOMS 的映射表被篡改时，Fabric 会对 PSP 的写请求执行静默丢弃，既不报错也不重试。这一行为使得 PSP 完全无法感知初始化数据实际上没有到达 DRAM。
这两个缺陷组合在一起，形成了一条完整的攻击链：恶意 UEFI 解锁 Fabric 配置 → 恶意 hypervisor 修改 IOMS 路由 → PSP 的 RMP 初始化写入被静默丢弃 → RMP 保持不安全状态 → 攻击者获得 CVM 内存访问权限。
受影响范围与 CVE 详情
根据 AMD 官方安全公告 AMD-SB-3034，Fabricked 影响的处理器范围覆盖了 Zen 3、Zen 4 和 Zen 5 全代 EPYC 产品线。研究团队在 AMD EPYC 9005 系列（Zen 5）上进行了完整验证并确认有效，AMD 则将固件修复扩展到了 7003（Milan）和 8004（Genoa）系列。嵌入式 EPYC 处理器同样在受影响范围内，包括面向服务器和特殊场景的 EPYC Embedded 系列。
该漏洞被分配为 CVE-2025-54510，CVSS 4.0 评分 5.9，评级为 Medium。需要特别注意的是，攻击的前提条件是攻击者已经拥有 UEFI 和 hypervisor 级的特权访问权限。这一定位使得 Fabricked 不是一个可被远程利用的漏洞，但它完美契合了云服务提供商内部的恶意管理员场景 —— 这正是机密计算所要防御的核心威胁模型。换言之，Fabricked 的意义在于证明了即使在 AMD 认为可信的威胁边界内，仍然存在一个被忽视的攻击面。
缓解措施：固件层与 TCB 版本要求
AMD 为 Fabricked 提供的缓解方案以 Platform Initialization（PI）固件更新的形式分发，具体通过各代处理器的平台初始化固件版本实现。EPYC 7003 系列需要 MilanPI 1.0.0.J，EPYC 8004 和 9004 系列需要 GenoaPI 1.0.0.H，EPYC 9005 系列需要 TurinPI 1.0.0.8。AMD 还为这些平台引入了 TCB [SNP]（Trusted Computing Base）版本检查，要求在远程证明中使用更高阈值的 TCB 版本以确保系统已应用缓解措施：Milan 平台要求 TCB [SNP] >= 0x1D 且 mitigation bit = 4，Genoa 平台要求 >= 0x1C，Turin 平台要求 >= 0x5。
对于嵌入式处理器，AMD 同样发布了对应版本的 Embedded Platform Initialization 固件。用户需要联系服务器原始制造商（OEM）获取针对其具体硬件配置的 BIOS 更新，因为固件更新的最终打包和分发由板级制造商负责。
工程实践中的检测与验证
对于已经部署的 SEV-SNP 环境，安全团队可以通过以下方式验证当前系统是否已应用缓解措施。首先，检查 SNP_FEATURES MSR 寄存器中的 TCB version 信息，确认其是否满足 AMD 公告中指定的最低版本要求。其次，在 AMD PSIRT 提供的修正固件发布之前，可以通过检查系统日志中是否存在异常的 SEV-SNP 初始化完成信号来初步判断 —— 如果初始化完成得异常迅速，可能暗示 RMP 写入被静默跳过。
研究团队在 GitHub 上提供了 Fabricked 的概念验证代码（https://github.com/fabricked-attack），但仅为学术用途。云服务商在评估自身安全状态时，应当关注 UEFI 固件来源的可信性 —— 由于攻击本身依赖于修改 UEFI 跳过锁定调用，使用开源或经过审计的固件替代方案是一种有效的纵深防御手段。
更大的安全图景：XCA 攻击族与互联层信任
Fabricked 是 XCA（Interconnect Corruption Attacks）攻击家族的一员。同家族的 BreakFAST 攻击针对不同的 Infinity Fabric 组件（I/O crossbar 而非 IOMS），实现了另一种路径的 PSP 操作劫持，但目标效果有所不同 ——BreakFAST 允许攻击者控制部分 Control Fabric，而 Fabricked 侧重于破坏内存完整性保护。值得注意的是，AMD 自己的安全公告中披露 Intel 也存在类似问题（INTEL-SA-00960），这表明互联层的配置信任传导是一个跨厂商的架构级问题。
这一发现对机密计算的安全评估具有深远影响。SEV-SNP 的信任根长期以来被理解为 PSP 硬件本身，而 Fabricked 表明 PSP 的正确运作依赖于一条完整的互联初始化链。如果这条链路上的任意一环 ——UEFI 配置、Fabric 锁定机制、IOMS 路由逻辑 —— 被破坏，PSP 的可信输出就变得毫无意义。这意味着机密计算的安全边界实际上延伸到了固件层和互联架构层，远比单纯关注 CPU 核心的隔离机制更为复杂。
资料来源：Fabricked 攻击页面（https://fabricked-attack.github.io）、XCA 攻击项目页面（https://xca-attacks.github.io）、AMD 安全公告 AMD-SB-3034（https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3034.html）。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。