Hardware fuzzing needs better tools and clear reporting to grow
SoK: You Find What You Seek: Rethinking Oracles, Guidance, and Input Generation in Hardware Fuzzing
Cryptography and SecurityHardware Architecture
Summary
Testing computer chips for security problems is harder than testing software, and the ways people fuzz software don't always work well for hardware. The authors looked at many hardware fuzzing methods and made a framework to understand how they search for bugs and what limits their success. They found hardware fuzzing can help in two main ways: improving existing testing methods and performing focused attacks based on security goals. They also suggest that hardware fuzzing will become more useful if it has reusable tools, clear results, and better ways to share effort and costs.
What this means in practice
- •For hardware verification engineers: Improve hardware testing by combining fuzzing feedback with traditional verification methods for better bug detection.
- •For security testing teams: Design targeted hardware attack scenarios using fuzzing guided by specific security threats and specifications.
A survey. It maps existing work.
Authors
G Abarajithan, Zhenghua Ma, Cristian Tirelli, Andres Meza, Francesco Restuccia, Cynthia Sturton, Ryan Kastner
Abstract
Hardware fuzzing is an active area in security verification research, yet its industrial adoption remains in its early stages. This SoK examines which lessons from software fuzzing carry over to hardware and where unique approaches are needed. By analyzing 52 fuzzers across RTL/IP, CPU, NoC, and SoC designs, we introduce an analytical framework that frames verification as a bounded search. This search is defined by its objective, oracle, guidance, input generation, target abstraction, and budget. Consequently, a campaign only uncovers failures it can effectively reach, recognize, and prioritize before exhausting its resources. We distinguish two roles for hardware fuzzing: (1) augmenting constrained-random verification (CRV) via feedback-guided coverage and (2) directed adversarial testing based on threat models and security specifications. Through our framework, we identify what each campaign can observe and generate, providing a basis for assessing the evidence behind reported results. Our analysis suggests that mainstream adoption of hardware fuzzing will require reusable interfaces, target-specific verification assets, reproducible evaluations, and transparent reporting of cost and user effort.