Pre-silicon fuzzing

Pre-silicon fuzzing is the application of fuzz-testing techniques to hardware designs before fabrication, with the goal of exposing design bugs or security weaknesses while the processor or hardware block is still available as a model, simulator, or register-transfer-level design. In processor-security research, recent work extends pre-silicon fuzzing beyond functional-correctness testing toward security-oriented fuzzing, including detection of side-channel leakage against formal hardware-software leakage contracts.^[1]

Motivation

Traditional hardware fuzzing is commonly aimed at finding functional correctness bugs. Such fuzzers generate many test programs or input sequences and look for architectural mismatches, crashes, or violations of expected behavior. However, functional bug oracles are not sufficient for many microarchitectural security problems: information leaks such as Spectre-style leakage can occur even when the architectural output remains correct.^[1]

A related line of work uses hardware-software leakage contracts, which specify side-channel security guarantees expected from a processor. These contracts provide a formal way to describe what information a processor implementation is allowed to leak through microarchitectural behavior. The central verification problem is checking whether a concrete hardware design complies with the contract. Formal verification can provide strong guarantees, but the cited work notes that existing verification approaches struggle to scale to industrial-sized designs.^[1]

Pre-silicon fuzzing is therefore attractive as a scalable bug-finding technique: it can be run against open-source or proprietary processor designs before tape-out, and it can guide test generation toward suspicious microarchitectural behavior.

Coverage-guided contract fuzzing

A recent formulation is coverage-guided hardware-software contract fuzzing. This approach combines fuzzing with leakage contracts by making information leakage observable during simulation. The method uses a self-compositional framework, in which related executions are compared so that leakage manifests as divergence in microarchitectural state.^[1]

The key idea is that a contract violation may not be visible in the architectural state, but it may be visible as a difference in internal microarchitectural state between two executions that should be indistinguishable under the contract.

Self-Composition Deviation

The cited work introduces Self-Composition Deviation (SCD) as a security-oriented coverage metric. Unlike generic coverage metrics that simply reward exploration of new code paths or hardware states, SCD is designed to guide the fuzzer toward execution paths that violate a leakage contract.^[1]

Conceptually, SCD measures deviations between self-composed executions. When two executions are expected to be equivalent with respect to the leakage contract but diverge in microarchitectural state, the fuzzer treats that divergence as useful feedback. This makes the fuzzing loop security-directed rather than purely functional.

Typical workflow

A contract-oriented pre-silicon fuzzing workflow can be summarized as follows:

1. Select a hardware design
   The processor or hardware component is evaluated before silicon fabrication, often through simulation.

2. Define or choose a leakage contract
   The contract specifies the allowed information flow or side-channel behavior.

3. Generate test programs or inputs
   The fuzzer produces instruction streams or other stimuli for the hardware design.

4. Run self-composed executions
   Related executions are simulated and compared so that leakage-relevant differences can be observed.

5. Measure security-oriented coverage
   Metrics such as Self-Composition Deviation are used to decide which generated tests are interesting.

6. Mutate and prioritize inputs
   Inputs that increase security-relevant coverage or expose microarchitectural divergence are retained and mutated.

7. Report candidate vulnerabilities
   Divergences that correspond to contract violations are investigated as potential side-channel vulnerabilities.

Evaluation on open-source processors

The coverage-guided leakage-contract approach was implemented and evaluated on two open-source RISC-V cores:

• Rocket Core, an in-order RISC-V core.
• BOOM, a more complex out-of-order RISC-V core.^[1]

The reported results show that coverage-guided strategies outperform unguided fuzzing. The evaluation also found that increased microarchitectural coverage led to faster discovery of security vulnerabilities in the BOOM core.^[1]

Relationship to other hardware verification techniques

Pre-silicon fuzzing sits between lightweight random testing and full formal verification:

In the cited work, the motivation is precisely this gap: verification offers strong guarantees but struggles to scale, while conventional hardware fuzzing scales better but is often blind to information leaks.^[1]

Significance

Pre-silicon fuzzing for leakage contracts is significant because it shifts hardware fuzzing from merely detecting functional bugs to detecting microarchitectural security violations. By using feedback such as Self-Composition Deviation, the fuzzer can prioritize executions that are more likely to expose side-channel leakage. This is especially relevant for modern processors, where speculative execution, out-of-order execution, and complex microarchitectural state can create leakage paths that are difficult to detect with architectural testing alone.

References

^[1]: Gideon Geier, Pariya Hajipour, and Jan Reineke, “Coverage-Guided Pre-Silicon Fuzzing of Open-Source Processors based on Leakage Contracts,” arXiv:2511.08443v2, subject: Cryptography and Security. The abstract states that hardware-software leakage contracts specify side-channel guarantees, that existing verification approaches face scalability challenges, that common hardware fuzzing targets functional correctness and can miss Spectre-like leaks, and that the proposed method uses self-composition and Self-Composition Deviation to guide fuzzing on Rocket Core and BOOM. DOI: https://doi.org/10.48550/arXiv.2511.08443.