Challenges and Design Considerations for Finding CUDA Bugs Through GPU-Native Fuzzing

本文针对异构系统中 GPU 软件栈内存安全不成熟的问题，指出当前依赖不忠实 CPU 转换的测试方法存在局限，并强调了行为忠实性对于设计原生 CUDA 模糊测试流程以发现 GPU 漏洞的关键作用。

要点

这篇论文探讨了一个非常紧迫的问题：随着人工智能和超级计算机越来越依赖“混合系统”（CPU+GPU），我们如何确保这些系统中负责“干重活”的 GPU 是安全可靠的？

为了让你更容易理解，我们可以把整个计算机世界想象成一个大型建筑工地。

1. 背景：老工头 vs. 新机器

• CPU（老工头）： 就像工地里经验丰富的老工头。几十年来，我们给老工头配了各种安全手册、监控摄像头和严格的检查流程（内存安全工具），所以老工头很少出大乱子。
• GPU（新机器）： 就像最近引进的、速度极快但操作复杂的巨型机器人。它们负责搬运砖块、搅拌水泥（处理 AI 和科学计算）。但是，因为太新了，没人给这些机器人配过安全手册。
• 问题： 现在，整个工地的安全都系在这些没经过严格测试的机器人身上。如果机器人发疯（出现漏洞），不仅砖块会乱飞，甚至可能把整个工地（用户数据）都毁了。

2. 现状的尴尬：用“翻译”来测试是行不通的

目前，研究人员想检查这些机器人有没有毛病，通常的做法是：

把机器人的指令“翻译”成老工头能听懂的语言，然后在老工头身上跑一遍测试。

这就好比： 你想测试一个潜水艇能不能在深海抗压，结果你把它拖到陆地上，用模拟软件跑了一遍。

• 后果： 虽然你在陆地上跑通了，但潜水艇在深海（GPU 的真实环境）里可能会因为水压（架构差异）而解体。
• 论文观点： 这种“翻译测试”是不诚实的（Unfaithful）。它漏掉了 GPU 独有的特性，导致很多致命漏洞被放过了。

3. 核心挑战：为什么直接在 GPU 上测试这么难？

作者指出，要在 GPU 上直接做“暴力测试”（Fuzzing，即疯狂输入各种数据看它会不会崩溃），面临四大难题：

1. 缺乏“安检门”（Sanitization）：
   • CPU 上有专门的安检门，能发现谁带了违禁品（内存错误）。但 GPU 上还没有这种设备。
2. 不会“乱猜”（Input Mutation）：
   • 测试需要随机制造一些奇怪的数据（比如把数字改成极大或极小）。但现在的测试工具不懂 GPU 的“方言”，随便改的数据 GPU 直接拒绝，根本测不到深层问题。
3. 看不清“路线图”（Coverage Tracking）：
   • 我们需要知道测试覆盖了机器人的哪些功能。但在 GPU 上，就像在黑暗中开车，很难看清哪些路被走过了。
4. 没有“启动钥匙”（Fuzzing Harness）：
   • 启动 GPU 程序需要复杂的准备步骤（初始化、编译等）。现有的测试工具不知道如何正确地把这把“钥匙”插进去。

4. 作者的解决方案：给 GPU 装上“原生”的体检仪

作者提出了一套**GPU 原生（GPU-Native）**的测试方案，就像直接给潜水艇装上水下传感器，而不是把它拖上岸。

• 自带“安检门”（GPU 原生地址消毒）：

  • 利用 NVIDIA 的工具（NVBit），直接在 GPU 芯片内部植入监控代码。就像给机器人装上了内置的 X 光机，它一边干活，一边自己检查有没有内存越界。
  • 亮点： 即使是 NVIDIA 不公开源码的“黑盒”程序，也能被检测。

• 聪明的“乱猜”（上下文感知与类型感知）：

  • 上下文感知： 不像以前那样盲目乱试，而是先帮机器人把“热身”动作做完（初始化环境），然后再开始疯狂测试。这就像先给潜水艇注水，再下潜，而不是直接扔进水里。
  • 类型感知： 测试工具学会了 GPU 的“语法”。如果机器人需要“整数”，测试工具就会专门生成“极大整数”或“负数”来试探；如果需要“数组”，就故意给一个空数组或形状错误的数组。这就像用机器人能理解的“暗号”去激怒它，看它会不会崩溃。

5. 初步成果：发现了很多盲区

作者用这套方法测试了 NVIDIA 官方提供的 11 个常用数学库（cuBLAS）。

• 结果令人震惊： 即使是用官方提供的标准测试数据，也只覆盖了不到 26% 的代码路径。
• 比喻： 这意味着我们以为机器人已经练熟了，但实际上它还有 74% 的功能区域是从未被检查过的盲区。如果这些盲区里有漏洞，后果不堪设想。

总结

这篇论文的核心思想是：不要再用“翻译”或“模拟”的方式来测试 GPU 了，那是在自欺欺人。

我们需要直接在 GPU 上建立一套原生的、智能的测试系统。这不仅是技术问题，更是一个道德责任——毕竟，现在世界上最先进的 AI 和科学发现，都运行在这些可能随时会“发疯”的硬件上。作者提出的方案，就是给这些高速运转的“新机器”穿上真正的防弹衣。

技术摘要

论文技术总结：通过 GPU 原生模糊测试发现 CUDA 漏洞的挑战与设计考量

1. 研究背景与问题定义 (Problem)

随着摩尔定律的终结，计算架构正从以 CPU 为中心的同质系统向 CPU 与 GPU 紧密集成的异构系统转变。尽管 CPU 软件栈经过数十年的安全加固（如静态/动态分析、内存安全工具链），但GPU 软件栈在内存安全性方面仍显幼稚且危险。

• 核心问题：异构系统中可被利用的漏洞（CVE）数量逐年上升，而现有的缓解措施往往依赖于不忠实的转换（Unfaithful Translations）。即，将 GPU 程序转换为 CPU 程序进行测试。
• 转换的缺陷：由于 CPU 和 GPU 在架构上的巨大差异，这种转换无法忠实反映 GPU 程序的真实行为，导致漏报（False Negatives）和误报（False Positives），无法有效捕捉针对 GPU 架构特有的内存安全漏洞。
• 伦理挑战：全球最先进的 AI 和科学工作负载部署在存在安全漏洞的硬件组件上，这构成了严重的伦理风险。

2. 现有挑战 (Key Challenges)

论文详细分析了在 CUDA 程序中实施模糊测试（Fuzzing）以保障内存安全所面临的四大核心挑战：

1. 缺乏地址消毒（Lack of Address Sanitization）：
   • 现有的 CPU 地址消毒技术（如 ASan）无法直接泛化到 GPU。
   • 缺乏在 GPU 上原生检测缓冲区溢出、释放后使用（Use-after-free）等漏洞的动态检查机制。
2. 缺乏输入变异（Lack of Input Mutation）：
   • 现有的 CPU 模糊测试变异算子缺乏 GPU 架构的领域知识。
   • 难以生成能有效触发高并行 CUDA 内核中内存安全漏洞的合法输入。
3. 缺乏覆盖率追踪（Lack of Coverage Tracking）：
   • 在 GPU 上追踪代码覆盖率极具挑战性，难以量化测试效果并指导生成更有意义的输入。
   • 缺乏针对 CUDA 代码的覆盖率引导机制。
4. 缺乏模糊测试桩（Lack of Fuzzing Harness）：
   • CUDA 程序需要特定的上下文初始化、即时编译（JIT）以及 CPU-GPU 协同执行。
   • 现有的 CPU 测试桩无法处理 GPU 特有的环境设置，导致测试资源浪费或产生大量误报。

3. 方法论与设计方案 (Methodology)

为了解决上述问题，作者提出了一种GPU 原生模糊测试管道（GPU-Native Fuzzing Pipeline），其核心设计理念是**“忠实性”（Faithfulness）**，即直接在 GPU 硬件上执行测试逻辑。

3.1 核心工具：NVBit

该方案利用 NVIDIA 的动态二进制插桩工具 NVBit，在 GPU 上直接进行插桩，无需定制硬件，支持闭源和开源的 CUDA 内核。

3.2 关键组件设计

A. GPU 原生地址消毒与覆盖率追踪

• 地址消毒器 (Address Sanitizer)：
  • 在 GPU 上对内存访问指令进行插桩。
  • 为 GPU 全局、局部和共享内存的每个单元（如 4 字节）以及指针维护元数据。
  • 在执行 CUDA 内核时，通过查找元数据来检测内存安全漏洞，利用 GPU 的并行性加速检测过程。
• 覆盖率分析器 (Coverage Profiler)：
  • 对 GPU 控制流指令进行插桩。
  • 维护每个控制流指令的执行次数元数据。
  • 将执行计数作为反馈，指导模糊测试器生成新的输入。

B. 上下文感知模糊测试 (Context-Sensitive Fuzzing)

• 问题：闭源 NVIDIA 库通常通过高层内核调用底层内核，直接测试底层内核需要复杂的上下文链。
• 解决方案：利用开源的 CUDA 库示例（Library Samples）作为基础。
  • 将执行过程划分为初始化（设置上下文、内存分配）、计算（调用高层/底层内核）和终止（数据回传、同步、释放）三个阶段。
  • 摊销开销：将初始化和终止阶段摊销到多次计算阶段中。模糊测试循环仅包裹“计算阶段”，在保持上下文不变的情况下反复变异输入并重新执行，从而大幅降低开销。

C. 类型感知变异 (Type-Aware Mutations)

针对 CUDA 内核的参数类型设计特定的变异策略，以绕过浅层的类型检查并触发边缘情况：

• 整数参数：变异为 0、最大正数、最小负数（触发溢出）。
• 浮点数参数：针对符号位、尾数和指数进行位翻转或数值加减。
• 数组参数：
  • 值变异：使用大数值、空数组、维度不匹配的数组。
  • 指针变异：将期望分配在全局内存的指针变异为指向局部或共享内存，以触发内存访问违规。

4. 初步实验结果 (Results)

作者在配备双 NVIDIA A100 GPU 的服务器上，对 NVIDIA 闭源库 cuBLAS 中的 11 个库示例进行了初步实验。

• 实验设置：Ubuntu 22.04, CUDA 13.1, 使用 NVBit 进行插桩。
• 覆盖率统计：
  • 测试结果显示，现有的 CUDA 库示例输入在 GPU 内核上的代码覆盖率非常低。
  • 几何平均覆盖率仅为 25.98%。
  • 具体案例：asum 覆盖率最高（64.29%），而 rotm 最低（9.09%）。
• 结论：这表明现有的测试输入在探索复杂 GPU 程序状态空间方面存在巨大缺口，验证了开发 GPU 原生模糊测试管道的必要性。

5. 主要贡献与意义 (Contributions & Significance)

1. 伦理责任的重申：论文强调系统设计师有伦理责任在 GPU 原生环境下验证程序的正确性，反对依赖不忠实的 CPU 转换测试。
2. 首个 GPU 原生模糊测试框架设计：提出了一套完整的、基于软件（NVBit）的 GPU 原生模糊测试方案，解决了地址消毒、覆盖率追踪、上下文管理和类型感知变异等关键难题。
3. 支持闭源生态：该方案能够在不修改硬件的情况下，对 NVIDIA 闭源 CUDA 库进行内存安全检测，填补了当前工具链的空白。
4. 提升检测效率：通过上下文感知和类型感知策略，显著提高了模糊测试在 GPU 上的有效性和效率，能够发现传统方法无法检测的新型 GPU 内存安全漏洞。

总结：该论文指出了异构系统安全中的严重差距，并提出了通过 GPU 原生模糊测试来填补这一差距的具体技术路径，对于保障 AI 和科学计算基础设施的安全性具有重要的理论和实践意义。