Hardware-Fuzz
GoldenFuzz (NDSS’26) → CURE-Fuzz (ICCAD’25) → GenHuzz (USENIX Security’25) → RLFuzz (HOST’25) → HFL (DATE’25) → ChatFuzz (DATE’24)
| 论文 | 发文场所 | 发文时间 | 解决的问题 | 解决问题所用到的技术 |
|---|---|---|---|---|
| GoldenFuzz | NDSS（CCF-A） 2026 | 2026-02 | 现有硬件 Fuzzing 中，测试用例优化往往频繁依赖 RTL/DUT 仿真，导致仿真开销高、测试生成吞吐率低；同时还需要更好地利用指令语义和依赖关系生成高质量测试程序。 | Golden Reference Model (GRM) + 两阶段 Fuzzing + 生成式测试程序构造。先在快速 ISA-compatible Golden Reference 上优化测试用例，再送入真实 DUT 验证；利用 instruction block 和反馈信息提升测试质量。 |
| CURE-Fuzz | ICCAD (CCF-B)2025 | 2025-10 | 传统 Coverage-guided Fuzzing 容易集中于已经被频繁访问的状态，对未知、稀有处理器状态探索不足；同时测试程序结构和控制流缺乏灵活控制。 | Curiosity-Driven Reinforcement Learning + Hierarchical Test Generation。引入内在好奇心奖励，激励 Agent 探索新颖硬件状态，并通过分层生成模型控制指令结构、控制流和依赖关系。 |
| GenHuzz | USENIX Security(CCF-A) 2025 | 2025-08 | 随机变异方法难以理解指令语义和复杂指令依赖，生成大量低价值测试程序；同时硬件覆盖反馈没有被充分用于指导生成。 | Language Model + Hardware-Guided Reinforcement Learning。利用语言模型生成具有语义及指令依赖的 RISC-V 程序，并使用真实硬件/RTL 的覆盖率反馈持续优化生成策略。 |
| RLFuzz | IEEE HOST 2025 | 2025-05 | 传统硬件 Fuzzer 的 mutation 策略通常采用人工设定或固定概率，不能根据当前硬件状态动态选择最有效的变异操作，导致覆盖率增长缓慢。 | Deep Reinforcement Learning / Deep Q-Learning (DQN) + Mutation Selection + Asynchronous Training。将 mutation operator 选择建模为 RL 决策问题，通过覆盖反馈学习最优变异策略，并并行执行 Fuzzing 与模型训练。 |
| HFL | DATE(CCF-B) 2025 | 2025-03 | Hardware Fuzzing 需要大量 iteration 才能提高覆盖率，并容易出现coverage saturation；缺少对测试程序覆盖潜力的有效预测。 | LSTM + Coverage Predictor + Reinforcement Learning Loop。使用 Multi-head LSTM 生成指令序列，通过 LSTM Coverage Predictor 预测测试质量，并利用真实硬件反馈形成强化学习闭环。 |
| ChatFuzz | DATE(CCF-B) 2024 | 2024-03 | 随机输入和简单 mutation 难以生成包含复杂数据流和控制流依赖的测试程序，因此对处理器深层状态空间探索不足。 | Language Model + Reinforcement Learning。首先学习汇编/机器指令语义，再利用有效指令反馈和 RTL coverage feedback 分阶段强化生成模型，使其生成更有效、更高覆盖率的测试程序。 |
GoldenFuzz
GoldenFuzz: Generative Golden Reference Hardware Fuzzing
leverages a golden reference model to efficiently explore processor states and reduce RTL simulation overhead
痛点
- 生成的测试不够好：现有 fuzzer 主要依靠随机变异或启发式规则，抓不住 ISA 里指令之间的依赖关系，因此产生大量重复用例，边界情况没有被探索到；论文还明确指出，先前工具有时生成的用例里可执行指令甚至不到 10 条。
- 优化效率不高：有些工作用控制流引导或强化学习来挑选用例，但“改进用例”和“探索覆盖”混在一起，导致两边效率都不高。
- 算力开销大：每次迭代都要在周期级精度的 DUT 仿真上运行一大批用例，速度慢到限制探索范围。
方法
-
用 Golden Reference Model 代替昂贵的 DUT 做前期反馈 不需要每生成一个测试都去跑很慢的 RTL 仿真，而是在更快的参考模型上评估测试质量。降低生成高质量测试的成本。
-
以 Instruction Block 为单位生成和优化测试 不只是随机拼单条指令，而是关注一组指令之间的组合与依赖关系，逐步构造高质量测试用例。让生成的指令序列更有意义。
-
利用好/坏测试的反馈持续优化，再拿高质量测试去测真实 DUT 根据覆盖率等反馈判断哪些指令组合有效、哪些效果差，用这些信息改进后续生成，最后把优化后的测试用于真实 CPU。先快速学会“怎么测”，再真正去“测 CPU、找 Bug”。
局限
-
依赖高质量的 GRM。 GoldenFuzz 的核心前提是存在一个快速、可信、ISA-compliant 的 Golden Reference Model。如果换到某种新 ISA、定制扩展或特殊硬件，而没有成熟 GRM，那么这套方法就不容易直接使用。GRM 自己如果存在错误，也可能影响测试生成和判断。
-
GRM 和真实 DUT 存在“抽象鸿沟”。 GRM 主要描述 ISA 层面的正确行为，而真正 CPU 还有 Pipeline、Cache、Branch Predictor、乱序执行等复杂微架构状态。在 GRM 上表现“好”的测试，不一定就是最能探索 DUT 微架构状态的测试。 GoldenFuzz 本身采用“两阶段”设计，只是把测试 refinement 与 DUT 上的 coverage/vulnerability exploration 部分解耦，并没有完全替代 DUT fuzzing。
-
Coverage 只是代理指标，不等于 Bug。 GoldenFuzz 很重视覆盖率，因为它需要一个信号判断测试有没有探索价值。Coverage 高只能说明“探索得广/深了一些”，不能保证一定进入了真正容易出 Bug 的状态。更一般的 coverage-guided fuzzing 研究也指出，只知道“执行了哪里”有时不足以描述“以什么状态、什么路径到达那里”。可能存在：
Test A → Coverage 很高 → 没 Bug Test B → Coverage 不突出 → 恰好触发关键 Bug -
目前验证范围仍然有限。 论文主要在 RocketChip、BOOM、CVA6 三个 RISC-V 处理器上评估，并额外测试了商业 BA51-H core extension；结果很好，但这并不能直接证明它对所有处理器、所有 ISA 和各种定制硬件都同样有效。