文章总结： 本文剖析NVIDIA矿卡纯软件解锁至A100算力的过程，揭示GPU信任栈四大缺陷：栈保护值存于可写内存被溢出绕过、无界DMA成静态分析盲区、确定性环境使离线仿真攻击极可靠、常开电源域致永久解锁。该研究动摇GPU机密计算信任根假设，建议勿将签名等同防主机安全，应强制MPU只读映射保护关键变量，并将DMA感知分析纳入CI流程。 综合评分： 92 文章分类： 漏洞分析,逆向分析,AI安全,二进制安全

一张矿卡撬动A100：从矿卡破解看GPU安全设计的系统性缺陷

Gach0ng Gach0ng

Khan安全团队

2026年7月18日 09:03 海南

在小说阅读器读本章

去阅读

翻到篇文章zenodo.org/records/20916112，大概是描述如何将一张被锁死在1/32算力、10GB显存、PCIe Gen1的NVIDIA CMP 170HX矿卡，可以纯靠软件手段变成一张接近A100规格的卡——31倍算力提升、8倍显存容量、2倍链路速度，全程不需要签名密钥、不需要调试接口、不需要物理开盖。

目标是一张NVIDIA CMP 170HX。这张卡在市面上定位是矿卡，跟A100是同一颗GA100芯片，但出厂被锁了：SM算力三十二分之一，显存只认10GB（实际上焊了80GB的HBM），PCIe缩在Gen1。官方说法是OTP熔丝永久锁定，硬件层面不可逆。

研究人员把这些限制全解了，没碰签名密钥、没接调试接口、没开盖，就靠软件。他们真正解掉的东西其实不只是这张卡——而是整个GPU信任栈里几个挺普遍的设计问题。下面按我自己的理解给出一些思考。

先说厂商这套信任栈长什么样。从下到上大概分三层：最下面是OTP熔丝，存的是物理熔断结果；中间是HS（Heavy Secure）模式下的固件，跑在硬件隔离区里，负责读熔丝、执行限制；最上层才是我们熟悉的签名校验、栈保护这些常规内存安全手段，用来保护HS模式本身不被篡改。三层环环相扣，但研究人员直接攻破了最上层。上层一穿，中间层对那几个特定轴的限制就不再起作用了。下图画的是这个分层结构和被击穿的位置。

第一个问题出在栈保护的参考字放错了地方。

栈保护的逻辑大家应该都熟，编译器在函数开头插一段代码，从__stack_chk_guard里取一个值压到栈上：

uintptr_t guard = __stack_chk_guard;stack_canary = guard;

函数返回前再读一次，对不上就崩：

if (stack_canary != __stack_chk_guard) __stack_chk_fail();

这个机制有效的前提是：__stack_chk_guard在整个函数调用期间不能被改。注意，是”不能被改”，不是”不能被猜”。但绝大多数工程实践都在强调后一个——熵值要高、每次启动要重新采样、要保密。NVIDIA在这方面做得挺到位，__stack_chk_guard在HS初始化时由硬件RNG重新播种，每次启动都不同，也不会暴露给主机。

问题出在哪儿呢？工具链默认把__stack_chk_guard放在了数据段的尾部，而Falcon的这片数据内存是平坦可写的，没有MPU只读映射，没有RELRO，没有guard page。这个参考字就待在普通全局变量的末尾，旁边正好是一个可溢出的签名缓冲区。

于是攻击手法变得异常简单：构造一个从签名缓冲区起始的线性溢出，用一个统一值V无脑往上填，一路踩过去——先盖掉__stack_chk_guard，再盖掉栈上保存的canary副本，最后盖掉返回地址。三个位置全变成V。尾声读参考字得V，跟栈上副本V一比，相等，通过，然后从栈顶弹出一个返回地址——还是V——跳过去。随机性、机密性、每次启动新鲜度，全跟你没关系了，因为你根本不需要知道原来是什么。

第二个问题是DMA在静态分析工具眼里几乎是隐形的。

具体的漏洞入口是一个无界DMA拷贝。LS签名验证例程通过DMA从主机拉签名数据到片上DMEM的固定缓冲区，长度来自攻击者可控制的结构体字段，目标缓冲区没做边界检查。

值得讨论的不是这单个bug，而是DMA这个操作在现有安全分析流程里几乎是个盲区。常规静态分析只追踪CPU指令和标准库函数，但DMA传输在代码层面就是几条寄存器写——锁存源地址、目标地址、长度，再写一个触发位——静态工具没法把这组操作识别成一次memcpy。更麻烦的是长度值本身也是从之前DMA读进来的结构体里取的，污点源也是DMA，工具根本追踪不到。

论文里有个对比实验挺有说服力：旧版bootloader的签名读取长度是常量或经过钳位检查的，检查器全过；新版bootloader引入了这个无界DMA，检查器唯一命中的风险点就在这。这恰恰说明厂商自己的审查流程也没把DMA当作一个会写内存的实体来对待——否则这种教科书级的溢出不可能过审。

第三个点是确定性环境让盲打变得异常可靠。

HS模式下，Falcon的指令内存和数据内存对外部读是锁死的，主机根本看不到栈里的实时状态。唯一的反馈通道是一个邮箱寄存器，能传的信息极其有限——一个值代表canary校验失败，另一个代表植入的自旋循环在跑。看不清现场，怎么知道往哪儿填？

答案就是这个环境没有不确定性。Falcon的微码没有并发、没有中断、没有操作系统调度、没有动态内存分配，每个周期的状态都是确定的。研究人员写了一个周期精确的仿真器，离线跑同一份bootloader镜像，就能精确还原出溢出那一刻的内存布局——guard在哪、canary副本在哪、返回地址在哪，全部算出来。更妙的是，因为用了均匀填充V，所有被覆盖的槽位统一成一个值，只需要让V指向IMEM里某个可用gadget就行。仿真器跑出来大概是这样：

# 非均匀填充，长度0xf800 → canary校验失败，进入abortREACHED SIG DMA: buffer=0x800 size=0xf800 overrun-end=0x10000 guard@0x6340 pc=0xfdef CANARY=True MBO=0xf47# 均匀填充 V=0x4a7 → 校验通过，PC跳转成功

这其实引出一个挺反直觉的结论：精简的确定性固件虽然减少了攻击面，但让漏洞利用变得极其可靠。攻击者不需要处理并发竞态、不需要绕过ASLR、不需要处理不确定的堆状态，脱机跑一遍仿真就全有了。安全关键路径上适当注入一些非确定性——比如随机化栈基址、随机偏移guard页、CFI里掺点随机分支——虽然不能根治问题，但能大幅提高利用门槛。

最后一个是常开岛让一次利用变成永久解锁。

攻击流程本身并不复杂。普通主机进程通过PCIe BAR0已经能读写寄存器，但熔丝覆盖相关的寄存器被PLM（特权级掩码）挡着，PL0级别写入硬件直接拒掉。攻击者加载厂商自己的已签名bootloader——签名校验正常通过——然后利用里面的无界DMA在HS模式下手动控制PC。拿到HS权限后重写PLM，把熔丝覆盖寄存器的写权限开放给PL0。之后主机直接用BAR0写寄存器把SM速率、显存配置、PCIe速度改掉。关键是这些覆盖值写在常开电源域里，功能级复位或者重装驱动都清不掉，攻击只需要跑一次。

解锁后的收益挺可观：FP32从约3 TFLOPS回到94 TFLOPS，31倍；FP64从0.2到12 TFLOPS；Tensor Core负载提升约15倍。显存从10GB变80GB，往全地址写不同哈希再读回来能确认都是真实物理地址。PCIe从Gen1拉到了Gen2。

不过也不是所有轴都能软件解。上边12根lane的交流耦合电容在PCB上直接没焊，必须补24颗100nF电容才能恢复×16——这是物理硬边界，软件碰不着。PCIe Gen3也一直没成，PHY校准参数疑似熔丝门控。HBM模式寄存器和片上ECC同样跑不通，所有能试的agent都被源ID锁挡住。这些轴目前的状态是”没找到方法”，不是”证明不可破”，但它们至少划了一条分界线：一边是纯软件能解的，另一边至少需要硬件改造或者更深的逆向。

延伸思考

这篇论文的威胁模型其实是反转的——攻击者是设备所有者，防御者是GPU固件代表厂商锁功能。看起来跟云上AI安全不直接相关，但有一个交叉点值得留意。

现在AI基础设施在推GPU机密计算，H100和Blackwell都支持Confidential Computing，目的是在多租户场景下保护模型权重和推理数据不被恶意主机或相邻租户读到。这套方案高度依赖HS固件作为信任根——假设HS模式能扛住来自主机的攻击，假设签名校验加栈保护能保证固件行为不可篡改。这篇论文直接动摇了第二个假设。一个内存安全漏洞——甚至不是0day，就在新版已签名bootloader里——就能让主机侧拿到HS执行权限。如果在机密计算环境里，恶意租户或被攻破的主机OS就可能突破隔离边界。

所以建议大伙：不要把”固件已签名”等同于”固件对恶意主机是安全的”。签名保证来源和完整性，但不保证没有内存安全缺陷。评估多租户GPU安全性时，应该要求供应商提供DMA-aware的安全分析报告，特别是对所有DMA sink的边界检查和长度来源做逐项审计。

另一个能落地的加固点：链接脚本。__stack_chk_guard放错位置这种问题在ELF的RELRO机制里早就解决了，但平坦内存Falcon镜像里MPU只读映射没有默认开。强制在链接脚本里把stack guard单独放一个段，初始化后用MPU设成只读——成本极低，但能直接把这种利用方式掐掉。

往远了看，GPU固件安全正在从”防用户”变成”防租户”，内存安全的解题工具也在变。Rust固件在一些嵌入式领域已经落地，如果HS Falcon能用内存安全语言重写，这类DMA无界拷贝在编译期就能拦住。但更现实的短期路径是把论文里那套DMA-aware静态分析推进到工程里——设备效应提升、污点传播、边界检查、链接映射、HAL契约、发布门控，逐层落地。已经有P2IM、HALucinator、DICE这些框架能自动建模DMA输入通道了，缺的只是从动态分析挪到静态审查的CI流水线里。

限于个人视野，文中观点难免存在疏漏。

感兴趣 AI 安全、网络安全的朋友，欢迎一起交流探讨。

联系方式：Gach0ng

免责声明：

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

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

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

本文转载自：Khan安全团队 Gach0ng Gach0ng《一张矿卡撬动A100：从矿卡破解看GPU安全设计的系统性缺陷》