Security researchers at the CISPA Helmholtz Center for Information Security have discovered a vulnerability they’ve called ‘GhostWrite’ that’s caused by a hardware bug in T-Head’s XuanTie C910 and C920 RISC-V CPUs. Vector extensions that are supposed to provide translation of virtual memory addresses to physical addresses don’t work, meaning that an attacker can gain access to the contents of memory and any attached devices.
The bug was found using RISCVuzz ‘Differential Hardware Fuzzing’ tool, which the researchers describe in a paper (pdf). They also discovered ‘Halt and Catch Fire’ bugs in T-Head C906 and C908 CPUs that could be exploited for denial of service attacks.
T-Head CPUs are used in the Systems on Chip (SoCs) that form the basis of many popular RISC-V development boards, such as the BeagleV®-Ahead and the Sipeed LicheePi4A. Modules built around those SoCs also show up in a variety of RISC-V-based laptops and other devices, along with Scaleway’s Elastic Metal RV1 RISC-V cloud servers.
The bugs make such systems unsafe for multi-user or multi-tenant environments with untrusted users, but that may not be an enormous problem in practice as dev boards and laptops tend to be single-user. Even the RV1 cloud servers provide an entire C910-based system rather than a slice of a more powerful system that’s typical for other types of cloud instances. Those servers might be used at a team level for continuous integration and other forms of testing, but it’s unlikely that the bugs will provide much additional risk to worry about within such teams. Scaleway have already added an entry to their RV1 FAQ for ‘Are EM-RV1 vulnerable to GhostWrite?’:
The kernel installed by default is not vulnerable to GhostWrite, we worked with CISPA security researchers to provide a fix before the disclosure. Installations made before the 6th of June 2024 are vulnerable, instruction to update your kernel are available here: EM-RV1 Guidelines: Update the kernel.
Where systems are (unavoidably) intended for use by untrusted users (or running untrusted code), the researchers recommend disabling the RISC-V vector extension within the operating system. They note that this "disables roughly 50% of the instruction set, severely impacting the CPU’s performance and capabilities."
The differential fuzzing technique used by RISCVuzz extends the normal fuzzing approach of running random instructions by looking for differences in the effect of those instructions across various implementations. That has allowed the CISPA team to find bugs in QEMU RISC-V emulation, as well as hardware bugs. As the RISC-V ecosystem continues to evolve it should prove to be a powerful way of ensuring that implementations are correctly aligned with the underlying Instruction Set Architecture (ISA) and extension specifications from RISC-V International.
It’s still early days for the adoption of RISC-V, with something of a "chicken and egg" situation between hardware manufacturers who are waiting for better software support and software developers who are waiting for better availability of test hardware. For instance Debian has support for RISC-V, but only in the ‘Sid’ unstable release. Ubuntu is also available for many RISC-V dev boards, but often with many caveats about missing drivers and implementation-specific patches.
It was a similar story for Arm a few years ago, and the test hardware problem was unblocked when Scaleway Arm-based cloud instances became available (which turned the getting hold of hardware problem into having funds to pay Scaleway problem). It looked like the pattern might repeat with Scaleway RISC-V instances, but that could now be impacted by concerns over the C910 - specifically, the performance impact of mitigating GhostWrite. Systems based on C910 SoCs generally land between the Raspberry Pi 3 and Pi 4 in performance benchmarks, so these aren’t high-performance systems even before applying mitigations.
In their FAQ the CISPA researchers clearly state that GhostWrite is a T-Head CPU problem rather than a more general problem with RISC-V. The neutral academic language of the RISCVuzz paper is less scolding of T-Head (and doesn’t highlight that no bugs were found in competing SiFive U54 and U74 CPUs) but does recommend that manufacturers should consider microcode as part of future designs to make hardware patches possible:
Given the increasing complexity of RISC-V CPUs, we advocate such a microcode layer on RISC-V to have the possibility of mitigating CPU vulnerabilities.