Artifact – RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs

This repository contains the artifact for the paper "RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs". It is archived on Zenodo.

Note

A standalone and updated version of the RISCover fuzzer is available here.

Note

This repository relies on Git LFS to handle large files. Please install it before cloning the repository. If you cloned without having LFS installed or have other problems with LFS files run: git lfs install && git lfs pull.

Abstract

This artifact accompanies "RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs" and provides the RISCover framework, a differential CPU fuzzer designed to uncover vulnerabilities in RISC-V silicon CPUs. The artifact includes the RISCover framework, evaluation scripts, and proof-of-concepts demonstrating the discovery of GhostWrite, an arbitrary physical write primitive on T-Head's C910, as well as the halting sequence bug in the C906. We provide detailed analyses of these vulnerabilities, exploitation case studies, and benchmarks of proposed mitigations. The artifact enables researchers to uncover new bugs with RISCover, to reproduce our findings, to compare RISCover against prior work such as Cascade, and assess the trade-offs of security mitigations on real hardware.

Structure

The repository is organized into the following directories:

• RISCover_framework: The RISCover differential CPU fuzzing framework (Sections 3-4).
• framework_eval: Evaluation of RISCover and comparison to Cascade (Sections 4-5).
• findings: Proof-of-concepts and reproducers for GhostWrite and other discovered bugs (Section 5).
• bug_analysis: Detailed analysis of GhostWrite and the C906 halting bug (Sections 6-7).
• ghostwrite_getuid_kernel_attack: Shows how to exploit GhostWrite for escalating privileges to the root user (Section 6).
• mitigations: Benchmarks and evaluation of mitigations (Section 8).

Set Up

The entire artifact uses Nix to easily provide the required packages for the various parts. Nix is a declarative package manager, i.e., needed packages can be specified in a file, locked via a lock file and then loaded reproducibly. Each directory contains a flake.nix or shell.nix, specifying the packages and environment. Nix can be installed on a large range of Linux distributions. If your distribution is not supported please fall back to the provided Docker container or a Docker container running, e.g., Ubuntu 24.04.

Important

Parts of the artifact (openC906 and openC910 simulation) run vendor-provided binaries that cannot be audited. If you do not want to take any risks we recommend to do the artifact evaluation in a container or VM.

Docker Environment (Recommended)

For ease of use, you can use the provided Docker container.

1. You can pull the container with:

   docker pull fabianthomas/riscover-artifact-cached:latest

   Alternatively, it can be built with:

   docker build . -t riscover-artifact

   This should finish rather quickly, but depending on the internet connection can take up to 10 minutes.

   The advantage of the build pulled from Docker Hub is that it comes with the Nix caches prefilled, so no recompilation should be necessary on top of building the Docker image.

2. Create a container (change the artifact mountpoint if needed):

   docker run -dit -v .:/mnt --name riscover-artifact <riscover-artifact or fabianthomas/riscover-artifact-cached>

3. Attach to container with:

   docker exec -w /mnt -it riscover-artifact bash

Native Installation (in Container or Native System)

1. Please install Nix. We recommend the multi-user installation if root privileges are available.

2. The artifacts further use an experimental Nix feature called Flakes. This feature needs to be enabled by running the following command:

   mkdir -p ~/.config/nix && echo 'experimental-features = nix-command flakes' > ~/.config/nix/nix.conf

3. Quickly verify that Nix Flakes work by running:

   nix run 'nixpkgs#hello'

   This should print "Hello, world!".

4. For automatically loading the environment for each directory the artifact uses direnv. With Nix already installed it can be simply installed by running:

   nix profile add 'nixpkgs#direnv'

   For other package managers refer to this page.

5. Please also setup your shell to automatically load the environment as specified here.

Quick Start & Basic Tests

For each directory, the provided environment has to be trusted first by running:

direnv allow

Run this now for the top-level directory.

Note

Loading the environment can take some time, depending on the used machine and experiment. This is because the RISC-V toolchain and libraries have to be partially build from source. If you use the cached Docker Hub build this should be instant.

Please run this command in the top-level (this) directory and verify that CC is correctly set to a static riscv64 (cross) compiler:

echo $CC # expected: riscv64-unknown-linux-musl-gcc

We provide a helper script direnv-allow-all.sh which finds, trusts and builds each environment. We recommend to run this once. Note that this will take a while (up to 3 hours), as all environments are built. After running the command, the environments are however cached.

You can now proceed to the following experiments. If you find any runtime or compilation errors it is likely that the Nix & direnv setup is somehow corrupted, as the artifact should provide all packages needed to run the experiments.

Experiments

In the following we list 10 experiments to reproduce the results from our paper. For each experiment, we list the machine that should be used.

E1: Test fuzzing campaign with RISCover (45 person-minutes)

Claim: RISCover discovers divergences across RISC-V CPUs.

Execution: Start diffuzz-server on the fuzzing server, connect T-Head XuanTie C910 and another RISC-V machine, and monitor results/reproducers/. Fuzz once with vector extension enabled, once disabled. When using the vector extension (--vector), the C910 should crash due to triggering GhostWrite. When not using the vector extension, reproducers are logged. Pick a reproducer, copy it to your machine, and reproduce it on one of the two machines using init-build-run-on. Find detailed instructions in RISCover_framework.

Expected Result: The C910 machine crashes due to GhostWrite. Without vector extension, reproducers are logged, indicating CPU state mismatches between the machines. Reproduced via yaml file.

Machines: For the server use any reasonably fast machine. For the clients, use a T-Head XuanTie C910 and another reasonably fast RISC-V machine.

E2: RISCover Overhead (45 person-minutes)

Claim: RISCover has low overhead with on-server input generation.

Execution: Follow the instructions framework_eval/overhead_eval.

Expected Result: 40% of the time of running on C908 is spent running inputs, with only 10% spent networking.

Machines: For the server use any reasonably fast machine. For the clients, use a T-Head XuanTie C908 and another fast RISC-V CPU.

E3: GhostWrite (15 person-minutes)

Claim: RISCover discovers GhostWrite, an arbitrary physical write primitive.

Execution: Run the GhostWrite reproducer in findings/ghostwrite_c910_arbitrary_physical_write.

Expected Result: GhostWrite writes to physical memory changing values observed from virtual memory.

Machine: T-Head XuanTie C910.

E4: GhostWrite Analysis (30 person-minutes)

Claim: GhostWrite bypasses caches and virtual memory.

Execution: Run the experiments in bug_analysis/ghostwrite/memory_interaction.

Expected Result: GhostWrite bypasses caches and directly writes to physical memory.

Machine: T-Head XuanTie C910.

E5: GhostWrite Simulation (30 person-minutes)

Claim: GhostWrite is not present in the openc910, the open-source RTL code of the C910.

Execution: Run the openc910 simulation in bug_analysis/ghostwrite/ghostwrite_openc910_simulation.

Expected Result: The vector extension cannot be enabled in simulation, so GhostWrite is not exploitable.

Machine: Any, preferably a fast machine with high parallelism.

E6: GhostWrite getuid Attack (30 person-minutes)

Claim: GhostWrite can be used to escalate privileges.

Execution: Run the attack in ghostwrite_getuid_kernel_attack.

Expected Result: GhostWrite allows for running su and gaining root user execution without password.

Machine: T-Head XuanTie C910.

E7: C906 Halting Sequence Simulation (30 person-minutes)

Claim: The C906 halting sequence can be reproduced in the RTL version (openc906).

Execution: Run the openc906 simulation in bug_analysis/bug_reproduction_openc906_halt_simulation.

Expected Result: The C906 halting sequence halts the core in simulation. The simulation ends after being stuck for a fixed number of cycles.

Machine: Any, preferably a fast machine with high parallelism.

E8: RISCover Weights Generation (15 person-minutes)

Claim: We can infer instruction weights from (Debian) RISC-V packages.

Execution: Follow the instructions in framework_eval/weights_generation.

Expected Result: We generate instruction weights from a sample set of Debian packages.

Machine: Any.

E9: Weighted Sequence Generation & Cascade Comparison (30 person-minutes)

Claim: RISCover's weighted sequence generation is effective in discovering bugs and performs similar to Cascade.

Execution: Follow framework_eval/rediscovering_bugs.

Expected Result: RISCover discovers 22 of the 23 bugs that Cascade discovers. The weighted sequence generation performs well, improving bug discovery in most cases.

Machine: Any, preferably a fast machine with high parallelism.

E10: Mitigation Benchmarks (45 person-minutes)

Claim: Disabling the vector extension prevents GhostWrite exploitation, while incurring a relatively high performance impact.

Execution: Run the benchmarks in mitigations on T-Head XuanTie C910.

Expected Result: Disabling the vector extension has a high impact (10-30%) on performance, measured via memset and memcpy.

Machine: T-Head XuanTie C910.