Newshot 
本周公开的两项攻击允许恶意主机读取受 AMD SEV-SNP 保护的虚拟机（VM）内部数据，而这些虚拟机旨在将服务器运营者拒之门外。
其中一项名为 Mior 的攻击还可以修改 VM 的内存，并伪造确认其运行哪款软件的签名报告。两者都需要控制服务器的 hypervisor，而 Mior 还需要控制服务器的 BIOS。研究人员在 AMD EPYC 服务器处理器上的实验室测试中展示了这两项攻击。
制造这些处理器的 AMD 将 Mior 对应的 SEV 固件和 Skyfall 对应的微码列为 8 月 12 日发布。它计划在 11 月向服务器制造商提供 Skyfall 的平台固件，在 12 月提供 Mior 的平台固件，稍后提供嵌入式芯片的修复。客户被告知要从其服务器制造商处获取 BIOS 更新。
SEV-SNP 将机密计算引入 AMD EPYC 服务器处理器。它使用硬件强制的内存加密和访问控制来保护 VM，甚至抵御主机的 hypervisor。
Mior 背后的 ETH Zurich 团队在 SEV-SNP 启动期间对它发起攻击。在启动过程中，芯片上的安全协处理器 Platform Security Processor（PSP）会填写一张名为 Reverse Map Table（RMP）的表。RMP 记录每个内存页的归属者以及他们可以对其执行的操作。
该团队将 PSP 的写入重定向到其控制的一张显卡的内存，而不是主内存。团队使用显卡是因为它认为 PSP 会回读这些值以进行检查，而显卡可以返回这些值。于是启动无错误完成，但真实 RMP 的一部分，包括保护该表本身的表项，仍未初始化。
这使 hypervisor 能够重写 RMP 的保护设置。团队随后在一台已禁用调试的机密 VM 上启用调试，并使用 PSP 自带的调试命令读取和写入该 VM 的内存。在两次测试运行的共 1,000 次尝试中，这一方法全部成功。
SEV-SNP 还会在 VM 启动时度量其软件镜像，并且 PSP 会对包含该度量值的认证报告进行签名。在第二项测试中，团队将一台无害 VM 的度量值复制到一台恶意 VM 中，因此恶意 VM 的认证报告描述的是无害镜像。
Mior 论文称，该攻击需要控制 hypervisor 和 BIOS（也称 UEFI），外加一个诸如显卡的 PCIe 设备。为进行测试，团队修改了 BIOS，使芯片的内存路由设置保持未锁定状态。
研究人员说：“我们在 AMD 为 SEV-SNP 定义的威胁模型中开展研究。AMD 明确不信任 UEFI，因此攻击者可以修改 UEFI。”
团队表示，普通 VM 本来就信任其主机及主机固件，因此 Mior 并未给攻击者提供针对它们的新能力。
团队在一颗 EPYC 9135（一款 Zen 5 芯片）上运行了 Mior。它认为 Zen 3 和 Zen 4 芯片可能受影响，但没有测试它们，因为其没有允许更改这些芯片 BIOS 的环境。
调试测试和认证测试都在启用密文隐藏的情况下成功。该可选的 SEV-SNP 功能会阻止 hypervisor 甚至读取加密的 VM 内存。
同一批研究人员中有人参与的早先两项攻击——Fabricked 攻击和 RMPocalypse 攻击——也在 SEV-SNP 启动时破坏了 RMP。团队表示，Mior 是一个单独的缺陷，与 Fabricked 及其修复无关。它在该修复之前的旧固件上也能奏效。
Skyfall 来自 ETH Zurich 和 Google 的一个团队。它基于 Transient Scheduler Attacks（TSA），这是一组 AMD 处理器中的缺陷，可通过指令时序泄露数据。TSA 最初于 2025 年 7 月 8 日披露。
文章标题：新型 Mior 与 Skyfall 攻击可让恶意云主机从 AMD SEV-SNP 虚拟机中窃取机密
正文： 该团队发现，当 hypervisor 故意导致虚拟机启动失败时，处理器已经缓存了该虚拟机部分已保存状态。这些数据在没有常规清理的情况下被遗留下来，hypervisor 可以通过 TSA 读取它。
通过这种方式，该团队从一台测试虚拟机中恢复了虚拟机的已保存寄存器值和一块磁盘加密密钥。对于密钥，他们修改了虚拟机的内核，使其在密钥位于寄存器中的那一刻暂停。该团队表示，在真实攻击中，hypervisor 可以改用一种名为 SEV-Step 的技术来单步执行虚拟机，直到密钥进入寄存器。
Skyfall 还可以读取虚拟机内存，但只能读取目标页面中三条固定的缓存行，偏移量分别为 0x0c0、0x380 和 0x3c0。页面其余部分则无法触及。
该攻击需要恶意的宿主或 hypervisor，但无需篡改硬件。该团队在 EPYC 7313（一款 Zen 3 芯片）以及 EPYC 9124 和 9334 芯片（属于 Zen 4）上进行了测试。它在 Zen 5 芯片上未显示出该泄漏。
除虚拟机之外，Skyfall 团队还在全部三款测试芯片上读取了解密后的微码更新。它还恢复了存储在系统管理模式（SMM）内存中的寄存器值，而即便是操作系统内核通常也无法读取该内存。这两类攻击都需要机器上拥有特权软件。
接收 Skyfall 论文的 IEEE Symposium on Security and Privacy 程序委员会表示，该论文忽视了针对虚拟机的现实攻击所需的条件。这包括一个无其他活动干扰的处理器核心、虚拟机启动失败以及高速读取性能计数器，还有一台在攻击期间不会崩溃或超时的虚拟机。
受影响的处理器与修复
AMD 在一份安全公告中将 Mior 追踪为 CVE-2026-0462，并在 CVSS 4.0 量表上将其评为 5.9。它在第二份公告中将 Skyfall 的虚拟机泄漏追踪为 CVE-2026-40671，评为 4.9，该公告将该缺陷描述为暴露虚拟机寄存器数据。
对于 Mior，该公司仅列出 SEV-SNP 受影响，而未列出更早的 SEV 和 SEV-ES 版本。
它为这两个缺陷列出了相同的五条 EPYC 服务器产品线，并给出以下修复：
| EPYC 系列 | Mior 平台固件（目标） | Mior SEV 固件（8 月 12 日） | Skyfall 平台固件（目标） |
|---|---|---|---|
| 7003 | MilanPI-SP3_1.0.0.L（12 月） | 1.3A.03 | MilanPI-SP3_1.0.0.L（11 月） |
| 8004 | GenoaPI_1.0.0.K（12 月） | 1.3A.4 | Genoa_100J Patch 3（11 月） |
| 8005 | TurinPI_1.0.0.C（12 月） | 1.3A.0A | TurinPI_1.0.0.C（11 月） |
| 9004 | GenoaPI_1.0.0.K（12 月） | 1.3A.4 | Genoa_100J Patch 3（11 月） |
| 9005 | TurinPI_1.0.0.C（12 月） | 1.3A.0A | TurinPI_1.0.0.C（11 月） |
这两份公告为同一个 TurinPI_1.0.0.C 包给出了不同的目标月份。针对 Skyfall 的微码在这些产品线上均标注为 8 月 12 日。Instinct MI300A 加速器有一个标注为 9 月 21 日的 Skyfall 补丁，而嵌入式 EPYC 型号的修复预计在 2027 年 1 月至 4 月之间。
Mior 团队表示，可缓解该缺陷的更新固件已经发布，Skyfall 团队也表示新的微码已经发布。公告未说明这些更新是单独生效，还是仅作为 BIOS 更新的一部分生效，也未列出任何变通方法。
服务器制造商 Supermicro 已发布一份 BIOS 修复列表，涵盖其数十款 H12、H13 和 H14 主板中的缺陷。同一批页面还称这些主板还需要更新 BMC 固件，并且该公司仍在测试受影响的产品。
由于修复是在宿主的固件中实现的，租用机密虚拟机的客户依赖于其云提供商来安装它们。涵盖 Mior 的公告还在每个已修复固件版本旁列出了用于 SNP 认证的 TCB（可信计算基）值。它未说明虚拟机所有者应如何检查这些值。
两份公告均未说明这些缺陷是否已被用于攻击。两个团队都已发布了代码，而 Mior 的概念验证代码需要一个经过修补、使内存路由设置保持解锁的 BIOS。
EDK II 项目为 Skyfall 的 SMM 泄漏分配了 CVE-2026-18448，并将其评为 5.6 分。AMD 的 EDK II 公告将其追溯到 EDK II 固件代码中缺失的 TSA 缓解措施。
该公告列出了 EPYC 和 Ryzen 芯片，包括嵌入式型号，并建议采用该公司早先的 TSA 缓解措施，以及在可用时应用 EDK II 补丁。
对于上面列出的五个 EPYC 服务器产品线，公告只列出了该补丁，预计 11 月发布。其他芯片（包括 EPYC 4004 和 4005 型号）已可获得包含该修复的平台固件。截至今日，EDK II 项目自己的公告未列出任何已修补版本。