
CPU Silicon Security Research and Fuzzing (RISC-V)
- Federico Maggi
- Hardware , Silicon , Security
- May 24, 2024
Table of Contents
I’ve embarked on a brief journey to learn RISC-V and I ended up finding a niche of interesting material on security research on fuzzing, so I pivoted my attention to that. Here’s a brief summary of what I found.
So far, I’ve been reading the following books.
- The RISC-V Reader: An Open Architecture Atlas (2017) by David Patterson (RISC-V Foundation, Google, Berkeley), Andrew Waterman (SiFive). This is a relatively brief but dense introduction to the ISA, with a nicely organized visual representation of all instructions in just half a page! You’ll learn the details of how instructions are encoded and admire the beauty of such a well-thought design.
- RISC-V Assembly Language Programming: using ESP32-C3 and QEMU (2022) by Warren Gay is a hands-on, slow-paced, journey of the RV32/64 instructions through examples that you can run immediately on your computer (QEMU) or on real RICV-V silicon (ESP32-C3).
How Popular is RISC-V as a Platform CPU?
Many hardware peripheral manufacturers use RISC-V blocks to make custom, powerful, and flexible management co-processors to run control firmware to manage the peripheral (e.g., GPUs). NVIDIA is integrating the open-standard RISC-V architecture into its products, initially using it for internal microcontrollers and more recently extending it to be a primary application processor by making its CUDA platform compatible with RISC-V CPUs.
RISC-V Cloud Offerings
However, RISC-V hasn’t yet reached a point where it may be a viable aleternative to, say, Intel, AMD, or ARM-based platform CPUs. However, we see some products and services at the horizon. To date, the following cloud providers offer RISC-V computing services.
ISA | Provider | Location | Processor | Manufacturer | Core Platform | Sources |
---|---|---|---|---|---|---|
RV64GC+V | Scaleway | France | Alibaba T-Head TH1520 | XuanTie | XuanTie C910 | C910 |
— | — | — | — | — | — | — |
RV64IMAC | Cloud-V | United States | FU540 discontinued | SiFive | nan | Freedom |
RV64GC | Cloud-V | United States | JH7100 | StarFive | SiFive U74 | Rocket + BOOM |
RV64GC | Cloud-V | United States | JH7110 | StarFive | SiFive U74 | Rocket + BOOM |
Mixed | Cloud-V | United States | microchip-icicle-kit , shakti_{c,e,u} , spike , virt | QEMU | cpu.h | - |
RISC-V Implementations
Needless to say, there are countless RISC-V boards. I stopped listing them when I realized there are quite some comprehensive lists around. Anyway, here’s my summary table based on the most comprehensive and maintained lists of RISC-V implementations:
- Alex Bradbury compiled a list of commercially available RISC-V silicons (last updated 2023-03-31).
- Aleksander Krimsky maintains a list of all commercially available RISC-V single-board computers (last updated 2024-05-01).
- RISC-V Wikipedia page (last updated 2024-05-24).
- RISC FIVE forum (last updated: 2023-03-09).
The list does not contain boards where the RISC-V block is not the main core (e.g., coprocessors).
Fuzzing Hardware Like Software
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.
RISC-V Fuzzing Experiments and Tools
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 | ๐ข |
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. |
Credits
Photo of the ESP32-C2 die: ESP32-C2 and Why It Matter-s