Research¶
RISC-V Fuzzing¶
RISCVuzz | Cascade (2024) | ProcessorFuzz (2023) | hw-fuzzing (2022) | DifuzzRTL (2021) | RFUZZ (2018) | |
---|---|---|---|---|---|---|
C910 | 🟢 | |||||
VexRiscv | 🟢 (7 CVEs) | |||||
PicoRV32 | 🟢 (6 CVEs) | |||||
Kronos | 🟢 (6 CVEs) | |||||
CVA6 | 🟢 (8 CVEs) | |||||
BOOM | 🟢 (2 CVEs) | 🟢 | 🟢 (2 CVEs) | |||
Rocket | 🟢 | 🟢 | 🟢 | |||
mor1kx | 🟢 (3 CVEs) | |||||
BlackParrot | 🟢 | |||||
Sodor | 🟢 | |||||
OpenTitan | 🟢 |
From a security standpoint, what makes RISC-V interesting is that the hardware definition of some IP cores is open source, which means that it can be formally verified and, best of all, fuzzed. Like software! The idea is "simple":
- compile the core into an executable format,
- shovel it into a simulator,
- randomize inputs (i.e., instructions and data),
- observe execution,
- measure coverage,
- repeat,
- ...wait, what now?
The design and implementation of such a fuzzer are quite challenging, mainly because, unlike with a traditional software program, it's difficult to define an oracle that tells us when a bug in a CPU design has been found, because a CPU just...interprets instructions based on state and data. It can't "crash". And if we observe a crash, most likely it's the simulator crashing. We don't yet have a precise way to tell whether the CPU being simulated and fuzzed is behaving according to the specs, or maybe according to the best golden model we have so far. Even in this case, is the golden model representative? What are we trying to compare against? We don't (yet!) have the choice of memory or address sanitizers like we have for fuzzers. In other words, there's a huge body of research, development, and hacking waiting to be unfolded. There exist the notion of coverage, which is good news.
Papers with Tools¶
I selected the following papers because (1) the evaluation is done on RISC-V cores or a full processor, and (2) they come with code, so the results are reproducible. In some cases, they're used to continuously fuzz the RTL of the cores, like in the case of the work by Trippel et al., which, according to the authors (and this repository), their tool is used to fuzz Google's OpenTitan.
- Fabian et al., RISCVuzz: Discovering Architectural CPU Vulnerabilities via Differential Hardware Fuzzing
- Tool: RISCVuzz
- Target RISC-V:
- Solt et al., Cascade: CPU Fuzzing via Intricate Program Generation, USENIX Security, 2024.
- Canakci et al., ProcessorFuzz: Processor Fuzzing with Control and Status Registers Guidance, IEEE HOST, 2023.
- Tool: ProcessorFuzz (Docker)
- Target RISC-V:
- BOOM (Chisel)
- BlackParrot (Verilog)
- Rocket (Verilog)
- Trippel et al., Fuzzing Hardware Like Software, USENIX Security, 2022.
- Tool: googleintern/hw-fuzzing (Docker)
- Target RISC-V:
- OpenTitan (AES, HMAC, KMAC, Timer)
- Hur et al., DifuzzRTL: Differential Fuzz Testing to Find CPU Bugs, IEEE S&P, 2021.
- Laeufer et al., RFUZZ: Coverage-Directed Fuzz Testing of RTL on FPGAs, IEEE/ACM ICCAD, 2018.
Known Vulnerabilities in RISC-V Designs¶
Design | Id | Bug Description | CWE | CVE | Researcher |
---|---|---|---|---|---|
VexRiscv | V1 | Non-deterministic conversion from single-precision float to int |
681 | 2023-34885 | Solt et al. |
VexRiscv | V2 | fmin with one NaN does not always return the other operand |
193 | 2023-34895 | Solt et al. |
VexRiscv | V3 | Conversion from double to float may pollute the mantissa |
681 | 2023-34895 | Solt et al. |
VexRiscv | V4 | Dependent arithmetic/muldiv FPU operations may yield incorrect results |
193 | 2023-34887 | Solt et al. |
VexRiscv | V5 | Equal registers may be considered distinct by fle.s and feq.s |
697 | 2023-34883 | Solt et al. |
VexRiscv | V6 | flt.s may return 1 when operands are equal |
697 | 2023-34883 | Solt et al. |
VexRiscv | V7 | Under some microarchitectural conditions, square root may be imprecise | 1339 | 2023-34891 | Solt et al. |
VexRiscv | V8 | Single-precision muldiv followed by conversion may pollute the mantissa |
681 | 2023-34895 | Solt et al. |
VexRiscv | V9 | Dependent arithmetic/muldiv operations may cause largely wrong output |
682 | 2023-34891 | Solt et al. |
VexRiscv | V10 | Operations on floating-point registers are authorized when FPU is disabled | 1189 | 2023-34885 | Solt et al. |
VexRiscv | V11 | Wrong access control to the FPU flags leaks information | 1189 | 2023-34885 | Solt et al. |
VexRiscv | V12 | Hang on speculatively executed compressed FPU instructions | 1342 | 2023-34896 | Solt et al. |
VexRiscv | V13 | Inaccurate instruction count when minstret is written by software | 684 | 2023-40063 | Solt et al. |
VexRiscv | V14 | Some register comparisons are still incorrect despite a partial fix | 697 | 2023-34883 | Solt et al. |
PicoRV32 | P1 | Accessing a non-implemented CSR causes the CPU to hang | 1281 | 2023-34898 | Solt et al. |
PicoRV32 | P2 | Spurious exceptions when reading mandatory CSRs | 1281 | 2023-34898 | Solt et al. |
PicoRV32 | P3 | Performance counters are not writable | 284 | 2023-34900 | Solt et al. |
PicoRV32 | P4 | Performance counters can only be read using some opcodes | 284 | 2023-34900 | Solt et al. |
PicoRV32 | P5 | Performance counter addresses are incorrect | 684 | 2023-34913 | Solt et al. |
PicoRV32 | P6 | Spurious exception when decoding fence instructions | 705 | 2023-34899 | Solt et al. |
Kronos | K1 | RaWaW double-hazard may cause a wrong register value to be forwarded | 226 | 2023-34906 | Solt et al. |
Kronos | K2 | Reading existing CSRs causes the CPU to hang in some uarch conditions | 1281 | 2023-34901 | Solt et al. |
Kronos | K3 | In some uarch conditions, no exception when writing inexistent CSRs | 1281 | 2023-41210 | Solt et al. |
Kronos | K4 | Inaccurate instruction count when minstret is written by software | 684 | 2023-40066 | Solt et al. |
Kronos | K5 | Incorrect decode logic for fence and fence.i |
684 | 2023-34903 | Solt et al. |
CVA6 | C1 | Double-precision multiplications yield wrong sign when rounding down | 682 | 2023-34904 | Solt et al. |
CVA6 | C2 | Single-precision floating-point operations may treat NaNs as zeros | 684 | 2023-34906 | Solt et al. |
CVA6 | C3 | Division by NaN incorrectly sets NX and NV flags |
682 | 2023-34905 | Solt et al. |
CVA6 | C4 | The inexact (NX ) flag not set in case of overflow or underflow |
684 | 2023-34905 | Solt et al. |
CVA6 | C5 | Division of zero by zero incorrectly sets the DZ flag |
684 | 2023-34905 | Solt et al. |
CVA6 | C6 | Plus and Minus infinity microarchitectural structures are inverted | 1221 | 2023-34910 | Solt et al. |
CVA6 | C7 | Infinities are not rounded properly and stick to infinity | 1339 | 2023-34910 | Solt et al. |
CVA6 | C8 | Spurious exceptions when reading some performance counters | 682 | 2023-34911 | Solt et al. |
CVA6 | C9 | Wrong supervisor performance counter access control | 684 | 2023-42311 | Solt et al. |
CVA6 | C10 | Under some microarchitectural circumstances, wrong NaN conversion |
682 | 2023-34908 | Solt et al. |
BOOM | B1 | Static rounding is ignored for fdiv.s and fsqrt.s |
1339 | 2023-34882 | Solt et al. |
BOOM | B2 | Inaccurate instruction count when minstret is written by software | 684 | 2023-40063 | Solt et al. |
BOOM | - | Misaligned lr instruction on a cached line set the reservation |
755 | 2020-29561 | Hur et al. |
BOOM | - | Source field in ProbeAckData does not match the sink field of ProbeRequest |
- | 2020-13251 | Hur et al. |
mor1kx | - | Reservation is not cancelled when there is snooping hit between lwa and swa |
- | 2020-13455 | Hur et al. |
mor1kx | - | Misaligned swa raise exception when reservation is not set |
- | 2020-13453 | Hur et al. |
Download: cves.csv