Overview

Mispredicted path fuzzing is a processor-verification technique used to exercise instructions and instruction addresses that appear only during speculative execution after a branch prediction or return prediction is wrong. In the Logic Fuzzer work, fuzzing allows a verifier to insert arbitrary instructions into the mispredicted path independent of the test binary, increasing coverage of instructions observed on that path. The paper reports that this enabled testing 100% of the instructions in the evaluated setting and reaching that coverage earlier than without fuzzing. [C1]

How it works

The technique perturbs predictor- and fetch-related microarchitectural tables so that the frontend observes atypical speculative control flow. The cited implementation uses Logic Fuzzer table mutators in two main ways:

• Branch target fuzzing: Branch Target Buffer entries can be fuzzed to return falsely predicted addresses over a broader range, or even random addresses at runtime. [C2]
• Return prediction fuzzing: The same approach can be applied to the Return Address Stack. [C2]
• Instruction injection on the mispredicted path: To insert random instructions into the mispredicted path, the implementation replaces instruction-cache tag and data arrays with table mutators, so the instruction-cache logic reads and writes through the fuzzer-controlled tables. [C3]

Because normal BTB predictions are derived from resolved branch-target history, unfuzzed predictions tend to remain within the address range encoded in the ELF file's .text section. With fuzzing enabled, BTB predictions can cover a broader or random address range, including non-typical cases that the processor should still handle robustly. [C4]

Verification integration

The Logic Fuzzer implementation described in the evidence is embedded in the Dromajo co-simulation infrastructure. The authors extended APIs so RTL can access fuzzers through DPI calls, with fuzzer behavior configured through Dromajo's JSON configuration file. For branch-predictor table fuzzing, the Dromajo-side fuzzer allocates a table with the same size as the branch predictor; the RTL then accesses this fuzzer table instead of the RTL memory model, and the table is fuzzed randomly or with specific patterns during simulation. [C5]

Failure model and caveats

Mispredicted path fuzzing may create microarchitectural states that no real program could reach. The Logic Fuzzer paper argues that co-simulation failures exposed under such states are still useful verification signals: they are potential bugs and should be investigated, proved, or disproved. The reported bugs in the paper were confirmed by designers. [C6]

Potential effects

By sending speculative execution to atypical targets, mispredicted path fuzzing can exercise edge cases such as instruction-TLB page faults on the mispredicted path. This makes the technique useful for checking whether the processor correctly recovers from unusual speculative frontend behavior. [C2]