asdfank/GSP_FUZZING

## 项目重点 本代码库是一个基于 kAFL 的研究型 fuzzing 项目，重点关注： - VFIO 设备直通下的多重快照 fuzzing， - GPU 驱动 fuzzing， - 硬件在环 执行模型， - 非确定环境下的可重现性与覆盖率收集。 该项目目前处于实验阶段，由一名开发者维护。 ## 硬件在环 Fuzzing 本项目探索在执行过程中与真实硬件交互的 fuzzing 目标。在此模型中，设备成为 fuzzing 循环的一部分，这直接影响覆盖率收集和快照可靠性。 ### 核心决策：重置是否可靠？ 硬件在环 fuzzing 设置在很大程度上取决于设备是否能在测试用例之间重置到已知的良好状态。 满足以下条件时，重置被认为是可靠的： - 设备和驱动程序返回到已知的良好状态， - 相同的测试用例产生相同的可观察行为和覆盖率， - 设备持续接受新工作，而不会出现超时风暴或持续的错误状态。 对于 GPU 等大型有状态设备，这一假设通常难以满足。大量的内部微架构状态可能会在普通设备重置后保留。实际上，某些设置可能需要完全的平台重启才能恢复真正干净的基线。 ### 如果重置可靠：快照可行 如果设备可以在输入之间恢复到已知的良好状态，则基于快照的 fuzzing 仍然可行。两种快照放置方式尤为相关： #### 1. 预初始化快照 在此模型中，快照是在驱动初始化之前拍摄的。 - 恢复到驱动加载前的状态 - 在每次迭代中重新运行设备枚举和驱动初始化 - 执行 harness 和测试用例 - 返回快照 这种方法较慢，但对于复杂设备通常更稳健，因为它避免了在迭代之间携带部分初始化的驱动或设备状态。 #### 2. 后初始化快照 在此模型中，快照是在驱动初始化完成后拍摄的。 - 恢复到初始化后的 guest 状态 - 重置设备 - 重建配置状态 - 执行 harness 和测试用例 - 返回快照以处理下一个输入 这种方法将昂贵的厂商驱动初始化排除在热循环之外，提高了迭代速度。然而，只有当设备和驱动状态能够以更廉价且确定的方式重置和重新准备时，它才有效。 ### 如果重置不可靠：禁用快照 如果无法实现可靠的重置，仍然可以通过完全禁用快照模式来进行 fuzzing。这更接近 syzkaller 风格的 campaign： - 输入之间不重置， - 高吞吐量， - 无法避免的状态漂移， - 降低的确定性。 这种模式可能仍然有用，但它给覆盖率和分类 带来了额外的挑战。 ### 覆盖率收集考量 在没有快照的情况下，guest 内存状态会随时间漂移。Intel PT 依赖于相对稳定的 guest 内存布局和基于页缓存的解码假设。在状态漂移的非快照系统中，PT 解码可能会停滞或遗漏执行，导致覆盖率变得不太可靠。 在可能的情况下，应将 KCOV 等软件插桩视为权威的覆盖率来源，而 PT 应仅被视为尽力而为。 ### 非确定性与反馈噪声 随着真实硬件加入循环，系统必须被视为非确定性的。 一个主要的故障模式是设备或驱动进入损坏状态，并开始对所有后续输入返回错误。当这种情况发生时： - 覆盖率可能停止变化， - 输入可能显得无趣并被丢弃， - 最初的崩溃或挂起输入可能无法通过重放验证，因为执行现在遵循不同的路径。 这使得分类和可重现性比普通的快照驱动 fuzzing 要困难得多。 ### DMA 警告 DMA 是异步的。测试用例可能会提交稍后完成的 DMA 工作，这意味着来自一次迭代的内存写入可能会在下次迭代期间落地，并污染反馈。 在接受下一个输入之前，系统应确保所有未完成的 DMA 活动已静止，或者重置和重新准备的强度足以防止 DMA 完成跨迭代泄露。 ### 这对本代码库的意义 本项目的长期目标是了解如何将 kAFL 风格的 fuzzing 工作流适配于 VFIO 直通和 GPU 驱动相关目标，在这些目标中，重置可靠性、快照放置、覆盖率收集和可重现性成为了核心的工程和安全挑战。

标签：Fuzzing, GPU驱动模糊测试, kAFL, KVM, QEMU, VFIO, Web报告查看器, 内核驱动安全, 内联执行, 多快照, 子域名枚举, 实验性框架, 客户端加密, 快照模糊测试, 文档安全, 状态重置, 硬件在环, 系统安全, 虚拟化安全, 覆盖率收集, 设备直通, 逆向工具, 配置错误