The GhostWrite vulnerability affects the T-Head XuanTie C910 and C920 RISC-V CPUs. This vulnerability allows unprivileged attackers, even those with limited access, to read and write any part of the computer’s memory and to control peripheral devices like network cards. GhostWrite renders the CPU’s security features ineffective and cannot be fixed without disabling around half of the CPU’s functionality.

Fundamentals.

Process Isolation and Assembly Instructions.

Modern operating systems work together with the CPU to keep each process running on your system isolated from the others. To do this, the operating system divides the physical memory into separate virtual memory spaces, one for each process. This ensures that each process can only access its own virtual memory and cannot interfere with other processes.

Your computer runs programs by executing instructions on the CPU. These instructions can range from very simple tasks, such as adding two numbers, to more complex operations. Usually, these instructions and their behaviors are thoroughly documented in the CPU vendor’s manuals. However, CPUs sometimes also contain undocumented instructions.

RISC-V logo

RISC-V.

A New CPU Architecture.

A CPU’s behavior is defined by an instruction set architecture (ISA), which specifies the valid assembly instructions. If two CPUs follow the same ISA, they can run the same programs.

Today, the CPU market is mostly dominated by two ISA specifications: x86 and ARM. These are controlled by a few companies, which limits how freely other companies can design their products. Using or modifying these ISAs requires expensive licenses and is restricted to a selected group of partners.

RISC-V is a new, open ISA that anyone can use and contribute to without restrictions. This openness has led to a thriving ecosystem, with continuous software improvements and new RISC-V-based hardware frequently emerging. You can even find RISC-V-based bare-metal servers in the cloud.

GhostWrite Illustration

GhostWrite.

Writing Arbitrary Physical Memory.

GhostWrite is a bug in the T-Head XuanTie C910 and C920, two of the fastest RISC-V CPUs available. Unlike side-channel attacks or transient-execution attacks, GhostWrite is a direct CPU bug. This CPU has faulty instructions in its vector extension, an add-on to the RISC-V ISA designed to handle larger data values than the base ISA.

These faulty instructions work directly with physical memory instead of virtual memory, bypassing the process isolation normally enforced by the operating system and hardware. This bug is embedded in the hardware, meaning it cannot be fixed with software updates.

An unprivileged attacker, for example, a normal user, can use these instructions to write to any memory location. This completely bypasses security and isolation features, giving the attacker full, unrestricted access to the device. The attack is 100% reliable, deterministic, and takes only microseconds to execute. Even security measures like Docker containerization or sandboxing cannot stop this attack. Additionally, the attacker can hijack hardware devices that use memory-mapped input/output (MMIO), allowing them to send any commands to these devices.

The only way to mitigate this issue is to disable the entire vector functionality, which disables roughly 50% of the instruction set, severely impacting the CPU’s performance and capabilities.

Demo

We show what GhostWrite can do with two proof-of-concept exploits.

In the first exploit, we use GhostWrite to modify the kernel’s getuid syscall. This function checks a user’s ID to decide what sudo should do. If getuid returns 0, which is the special ID for the privileged root user, sudo gives root access without asking for a password.

On its own, GhostWrite can only write to memory. However, it can be used to create a read function by modifying the page tables in memory. These tables translate virtual memory addresses to physical ones. Consequently, modifying them allows an attacker to get an accessible virtual address for any physical address, allowing reading and writing.

The second exploit shows how this GhostWrite-based read function can leak any memory content from a machine. To demonstrate this, we assume an administrator types a secret password into a trusted password prompt to update the system (left).

The exploit (right) starts by filling the physical memory with page tables. Given that the victim system has 8GB of memory, this process takes a few seconds. The exploit then attempts to modify one of these page tables using GhostWrite. Once successful, the exploit can read the secret password directly from physical memory.

Security Implications

To the best of our knowledge, only the T-Head XuanTie C910 CPU in the TH1520 SoC and the T-Head XuanTie C920 CPU in the SOPHON SG2042 are affected by GhostWrite. Still, this vulnerability impacts a wide range of devices, including personal computers, laptops, containers, and virtual machines in cloud servers. Therefore, any customers or vendors using machines with these processors are at risk. The vulnerability is tracked as CVE-2024-44067.

Vulnerable devices include:

To protect against this vulnerability, you can disable the vulnerable vector extension entirely.

An overview of differential CPU fuzzing.

Automatic Bug Discovery.

Differential CPU Fuzz Testing.

We discovered GhostWrite by analyzing both documented and undocumented instructions using a method called differential fuzz-testing for CPUs. The concept is intuitive: generate small programs, run them on different CPUs, and compare the results. Since every RISC-V CPU should follow the RISC-V specification, they should produce the same results for the same inputs. When results differ between CPUs, it suggests that one of the CPUs might have an issue.

We identified GhostWrite when the T-Head XuanTie C910 CPU showed unusual behavior with an illegally-encoded vector-store instruction. While other CPUs generated page fault exceptions or refused to execute the instruction, the C910 did execute it.

Upon further investigation, we discovered that the illegally-encoded instruction allows a process to write directly to physical memory instead of virtual memory, revealing a severe security vulnerability.

Who found it?

Acknowledgements

This work was supported in part by Semiconductor Research Corporation (SRC) Hardware Security Program (HWS) and by a Google Research Scholar award. Any opinions, findings, conclusions, or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding parties.

FAQ

Am I affected by this vulnerability?

Most likely, you are not affected directly. Only individuals that use vulnerable RISC-V hardware, such as C910-based or C920-based single-board computers (SBCs), cloud deployments, or other multi-party computing solutions are directly affected. Even though you might not be affected directly, the chance is high that you might already or in the future interact with vulnerable devices.

How do I know if my device uses the T-Head XuanTie C910 or C920 CPU?

Most consumer devices list their CPU specifications in their technical details or documentation. You can check the manufacturer’s website, user manual, or device settings for this information.

Can software updates or patches fix this vulnerability?

No, software updates or patches cannot fix this vulnerability because it is a hardware bug. The only mitigation is to disable the vector extension in the CPU, which unfortunately impacts the CPU’s performance.

How to mitigate GhostWrite? How do I protect devices against this vulnerability?

Luckily, the vulnerable instructions lie in the vector extension, which can be disabled by the operating system. This fully mitigates GhostWrite, but also fully disables vector instructions on the CPU. Linux can be compiled with CONFIG_VECTOR=n or CONFIG_RISCV_ISA_V=n depending on the source tree, which disables all vector-related code paths and thereby keeps the vector extension disabled.

What should cloud service providers do to protect their users?

Cloud service providers should disable the vector extension on any vulnerable CPUs and inform their customers about the potential impact on performance.

What are the performance impacts of disabling the vector extension?

Disabling the vector extension significantly reduces the CPU’s performance, especially for tasks that benefit from parallel processing and handling large data sets. Applications relying heavily on these features may experience slower performance or reduced functionality. In our benchmark using rvv-bench, we see up to 33% overhead when disabling the vector extension.

Is this a side-channel or transient-execution attack?

No, GhostWrite is an architectural bug and does not fall into the category of transient-execution attacks like Meltdown or Spectre. It is also not a side-channel attack.

Is there any evidence of this vulnerability being exploited in the wild?

To exploit the vulnerability an attacker needs to execute unprivileged code on the vulnerable CPU. This is a threat on multi-user and cloud systems or when untrusted code is executed, even in containers or virtual machines. As of now we haven’t heard of any occurrences where this vulnerability has been exploited in the wild.

What is the official statement of T-Head?

We reported the bug to T-Head. They acknowledged and reproduced it. However, we are unware of any planned public comments or mitigations.

Can GhostWrite be detected or monitored in some way?

As of now, there are no specific tools or methods to detect if GhostWrite is being exploited.

Does this mean that RISC-V is bad?

GhostWrite is not a problem with the RISC-V ISA. Only the T-Head XuanTie C910 and C920 CPUs, implementations of RISC-V, are vulnerable to GhostWrite due to a bug in their design.

Are there any alternative RISC-V CPUs that do not have this vulnerability?

Yes, many other RISC-V CPUs are not affected by GhostWrite. The vulnerability is specific to the T-Head XuanTie C910 and C920 CPUs.

What is CVE-2024-44067?

CVE-2024-44067 is the official reference to GhostWrite. CVE is the standard for information security vulnerability names maintained by MITRE.

Can I use the logo?

The logo is free to use, rights waived via CC0. Logo designed by Lea Mosbach.

Logo with text

Logo without text