GhostWrite Vulnerability in C910 and C920 RISC-V Processors

Security researchers at the CISPA Helmholtz Center for Information Security have discovered a security flaw they’ve dubbed “GhostWrite” that’s caused by a hardware bug in T-Head’s XuanTie C910 and C920 RISC-V processors. Vector extensions that should translate virtual memory addresses to physical addresses don’t work, meaning an attacker can access the contents of memory and any connected devices. The bug was found using the RISCVuzz “Differential Hardware Fuzzing” tool, which the researchers describe in a paper (pdf). They also discovered “Halt and Catch Fire” bugs in T-Head’s C906 and C908 processors that could be used to perform denial-of-service attacks.

T-Head processors are used in the Systems on Chip (SoCs) that underpin many popular RISC-V development boards, such as the BeagleV®-Ahead and the Sipeed LicheePi4A. Modules built around these SoCs also appear in various 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 in practice this may not be a huge problem, since development boards and laptops are typically designed for a single user. Even RV1 cloud servers provide an entire C910-based system, rather than a slice of a more powerful system that is typical of other types of cloud instances. These servers can be used at the team level for continuous integration and other forms of testing, but bugs are unlikely to be an additional risk to worry about in such teams. Scaleway has already added an entry to their RV1 FAQ titled “Is EM-RV1 vulnerable to GhostWrite?”:

The default installed kernel is not vulnerable to GhostWrite, we worked with CISPA security researchers to provide a fix before disclosure. Installations performed before June 6, 2024 are vulnerable, instructions on how to update the kernel are available here: Guidance EM-RV1: Update the Kernel.

For systems that are (inevitably) intended to be used by untrusted users (or run untrusted code), the researchers recommend disabling RISC-V vector extension in the operating system. However, they note that “this disables about 50% of the instruction set, which severely impacts the performance and capabilities of the processor.”

The differential fuzzing technique used by RISCVuzz extends the normal fuzzing approach of running random instructions by looking for differences in how those instructions behave in different implementations. This allowed the CISPA team to find bugs in the QEMU RISC-V emulation, as well as hardware bugs. As the RISC-V ecosystem evolves, this should prove to be an effective way to ensure that implementations are properly aligned with the underlying Instruction Set Architecture (ISA) and RISC-V International Extensions specifications.

It’s still early days for RISC-V, with a chicken-and-egg situation between hardware manufacturers waiting for better software support and software developers waiting for better availability of test hardware. For example, Debian supports RISC-V, but only in the unstable “Sid” version. Ubuntu is also available for many RISC-V development boards, but often with a lot of caveats about missing drivers and implementation-specific fixes. It was similar with Arm a few years ago, and the test hardware issue was unblocked when Scaleway Arm cloud instances became available (which turned the problem of getting the hardware into the problem of having the funds to pay Scaleway). It looked like this pattern might repeat itself with Scaleway RISC-V instances, but now it may be due to concerns about C910 – in particular the performance impact of GhostWrite mitigation. Systems based on the C910 SoC typically fall between the Raspberry Pi 3 and Pi 4 in performance tests, so they are not high-performance systems even before mitigations are applied.

In their FAQ, CISPA researchers clearly state that GhostWrite is a T-Head processor issue, not a more general RISC-V issue. The neutral academic language of the RISCVuzz article is less a scolding of T-Head (and does not emphasize that no bugs were found in the competing SiFive U54 and U74 processors), but advises manufacturers to consider microcode as part of future designs to enable hardware fixes:

Given the increasing complexity of RISC-V processors, we advocate for a microcode layer on RISC-V processors that could mitigate security vulnerabilities in the processors.