文章总结： CISPA团队披露AMD全系列服务器CPU存在硬件级StackWarp漏洞，攻击者利用未公开Hypervisor控制位干扰StackEngine，使虚拟机堆栈指针错位，实现控制流劫持、私钥窃取与内核代码执行；需立即更新微码并在机密场景禁用SMT。 综合评分： 92 文章分类： 漏洞分析,硬件安全,云安全,威胁情报,安全建设

当 Stack Engine 背叛了 CPU：详解 AMD 最新硬件级漏洞 StackWarp

原创

Hankzheng Hankzheng

技术修道场

2026年1月21日 07:57 广东

大家好，在这个云原生的时代，我们总被灌输一个概念：“只要上了云，开启了机密计算，你的数据就是安全的，连云厂商的管理员都看不了。”

真的是这样吗？

今天我们要聊的这个漏洞，可能会让你对“硬件级安全”产生新的怀疑。就在最近，德国 CISPA 信息安全中心的顶级白帽团队又搞了个大新闻。他们发现了一个代号为 StackWarp 的新型硬件漏洞，直接打穿了 AMD 引以为傲的 SEV-SNP 防护体系。

最让人头皮发麻的是，这次受影响的范围极大——从 Zen 1 到最新的 Zen 5 架构，几乎全线 AMD EPYC 服务器处理器无一幸免。

今天，咱们就脱去那些晦涩的英文术语，用工程师的视角来扒一扒：这帮研究员究竟是怎么隔着加密内存，把手伸进虚拟机里的？

01 所谓“固若金汤”的 SEV-SNP

在深入漏洞之前，得先聊聊受害者：AMD SEV-SNP（Secure Encrypted Virtualization with Secure Nested Paging）。

简单来说，这是一种通过硬件加密虚拟机内存的技术。它的核心逻辑是：Hypervisor（宿主机管理程序）是不可信的。

通常情况下，云厂商的管理员或者被攻陷的 Hypervisor 可以随意 dump 虚拟机的内存。但开了 SEV-SNP 后，内存是加密的，CPU 只有在虚拟机内部运行时才解密。理论上，就算黑客拿到了宿主机的最高权限，看着你虚拟机里的数据也应该是一堆乱码。

但是，StackWarp 的出现，告诉了我们一个残酷的现实：“我不看你的数据，但我可以改你的脑回路。”

02 核心原理：当“微架构优化”成为后门

这次漏洞的攻击点非常刁钻，它没有去硬破解加密算法，而是瞄准了 CPU 内部一个为了提升性能的微架构组件——Stack Engine（堆栈引擎）。

什么是 Stack Engine？

我们都知道，程序运行时频繁涉及入栈（Push）和出栈（Pop）操作，这需要不断修改堆栈指针（RSP/ESP）。为了不让这些频繁的加减法堵塞 CPU 的主流水线，现代 CPU 设计了一个专门的“小助手”叫 Stack Engine，专门负责推测性地更新堆栈指针。

漏洞在哪里？

CISPA 的大神们发现，AMD 的处理器在处理某些特定指令时，Stack Engine 和实际的架构状态之间存在同步间隙。

更致命的是，他们找到了一个未公开的 Hypervisor 控制位。

技术实锤：

攻击者如果拥有宿主机的管理员权限，可以通过操纵这个未公开的控制位，干预 CPU 的流水线配置。当攻击者在目标虚拟机隔壁的逻辑核（Hyperthread）上运行时，利用这个控制位，可以强制导致目标虚拟机内部的 Stack Engine 状态与内存中的实际状态失去同步。

结果是什么？

虚拟机以为它的堆栈指针（SP）指向的是安全区域 A，但实际上，攻击者已经通过硬件层面的干扰，把 SP 指向了攻击者预设的区域 B。

这好比你以为你在写日记（受保护的内存），结果有人悄悄把你桌子挪了，你闭着眼把字写到了隔壁老王递过来的一张纸条上。

03 攻击后果：从 ROP 到私钥窃取

既然控制了堆栈指针（Stack Pointer），对于咱们搞技术的人来说，接下来的剧本就很熟悉了。

• 1. 控制流劫持 (Control Flow Hijacking)

  只要修改了 SP，当函数返回（RET）时，程序就会跳转到攻击者想要的地方。这就是经典的 ROP（面向返回编程）攻击，只不过这次是在硬件层面触发的。

• 2. 数据流篡改

  攻击者可以让虚拟机把敏感数据“误”写入到非加密的共享内存区域，或者篡改关键的决策变量。

• 3. 实战演示——秒破 OpenSSH

  研究团队展示了惊人的攻击效果：利用 StackWarp，他们可以在一次错误的签名过程中恢复出 RSA-2048 私钥。 更进一步，他们直接绕过了 OpenSSH 的密码认证和 Sudo 的密码提示，在虚拟机内核模式下实现了代码执行。

一句话总结：Hypervisor 虽然看不懂你的加密内存，但它能让你自己把钥匙交出来，或者让你自己把门打开。

04 受影响产品与解决方案

这次受影响的名单基本上涵盖了市面上主流的 AMD 服务器 CPU：

• AMD EPYC 7003 “Milan”
• AMD EPYC 8004 “Siena”
• AMD EPYC 9004 “Genoa”
• AMD EPYC 9005 “Turin”
• 以及对应的嵌入式系列

怎么修？

AMD 官方给出的定性是 CVE-2025-29943 (CVSS 4.6 分，中危)。虽然利用门槛高（需要宿主机权限），但在公有云场景下，也是不容忽视的。

作为运维和开发，我们需要做两件事：

1. 打补丁（Microcode Update）： AMD 已经开始在 2025 年 7 月和 10 月发布微码更新，部分新型号的 AGESA 补丁要等到 2026 年 4 月。赶紧检查你的服务器 BIOS/固件更新列表。

2. 关闭超线程（SMT）—— 这是一个痛并快乐着的决定： StackWarp 攻击极其依赖于攻击者运行在与受害者相邻的超线程（Hyperthread）上。引用研究员 Ruiyi Zhang 的建议：

“Check whether hyperthreading is enabled… plan a temporary disablement for CVMs.”

如果你的业务跑在极高安全需求的机密虚拟机（CVM）上，建议立刻禁用 SMT。 虽然这会损失性能，但在补丁打上之前，这是唯一 100% 阻断攻击路径的方法。

05 笔者的思考

StackWarp 并不是孤例。从之前的 CacheWarp 到现在的 StackWarp，我们可以看到一个趋势：云安全的攻防战，正在从软件层下沉到微架构层。

以前我们防的是代码漏洞，现在我们要防的是 CPU 设计时的“聪明的优化”。那些为了榨干性能而设计的预测执行、堆栈引擎，在黑客眼中，全都是侧信道攻击的天然温床。

对于我们这些依靠云吃饭的技术人来说，盲目信任“硬件级安全”的时代已经过去了。纵深防御（Defense in Depth），永远不过时。

你怎么看这次 AMD 的“翻车”？欢迎在评论区留言交流！

参考资料：

• CISPA Helmholtz Center for Information Security
• The New Stack: StackWarp Hardware Flaw
• AMD Security Bulletin CVE-2025-29943

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng Hankzheng《当 Stack Engine 背叛了 CPU：详解 AMD 最新硬件级漏洞 StackWarp》