GhostWrite Under the Hood: How T-Head RISC-V Processors Allow Unprivileged Memory Overwrite Bypassing MMU and Page Tables

In the evolving landscape of microprocessor security, the open-standard RISC-V instruction set architecture has been championed as a transparent, auditable alternative to proprietary x86 and Arm silicon. But open architecture specifications do not automatically guarantee bug-free silicon implementation. Discovered in mid-2024 by security researchers at the CISPA Helmholtz Center for Information Security, GhostWrite (CVE-2024-44444) represents one of the most catastrophic hardware vulnerabilities ever fabricated into commercial silicon. Affecting the widely deployed T-Head XuanTie C910 and C920 processor cores—which power commercial edge-AI clusters, cloud development boards, and 64-core RISC-V servers worldwide—GhostWrite completely dismantles 100% of modern operating system security boundaries. Unlike transient execution side-channels (Spectre/Meltdown) that merely infer cached bytes through statistical timing noise, GhostWrite grants an unprivileged, sandboxed attacker the capability to directly read and write arbitrary physical RAM—completely bypassing Memory Management Units (MMUs), page table permissions, and supervisor isolation with a single unprivileged instruction.

1. The Memory Management Unit (MMU) & Page Table Isolation Model

To grasp why GhostWrite is so devastatingly unique, one must examine the foundational security guarantees of contemporary computer operating systems. Modern computing environments rely fundamentally on hardware-enforced isolation. When multiple software applications, unprivileged users, or isolated virtual containers execute concurrently on a single CPU, the operating system must ensure that no process can read or overwrite the memory of another process or the kernel.

Since the advent of virtual memory in the 1960s, operating systems have enforced process isolation using a hardware Memory Management Unit (MMU). Software processes never interact with physical DRAM directly. Instead, every software thread operates inside its own isolated Virtual Address Space.

When an application executes a memory load or store instruction:

The MMU references multi-level page tables managed exclusively by the operating system kernel. In 64-bit architectures, this translation typically traverses a 4-level or 5-level radix tree (e.g., Sv39, Sv48, or Sv57 in RISC-V). Each Page Table Entry (PTE) encodes critical security bits that govern CPU execution:

• User/Supervisor Bit (\(U\)): If \(U=0\), userspace applications running in unprivileged mode (User Mode / U-mode / EL0) are physically prohibited from reading or writing the page.
• Read/Write Bit (\(W\)): Enforces read-only memory segments (such as executable code (.text) and constant data (.rodata)), preventing unauthorized modifications to program logic.
• Execute-Never Bit (\(XN/NX\)): Prevents executing malicious payload code injected into writable stack or heap buffers, thwarting classic buffer overflow exploits.
• Valid Bit (\(V\)): Indicates whether the physical page is currently mapped into physical RAM or paged out to disk storage.

If an unprivileged process attempts to read or write a physical memory page belonging to another container, a neighboring virtual machine, or the operating system kernel, the MMU hardware immediately intercepts the transaction, aborts the instruction pipeline, and triggers an unrecoverable Page Fault (SIGSEGV) exception, terminating the rogue process before any unauthorized memory access can occur.

2. The Microarchitecture of XuanTie C910 & The Silicon Erratum

Alibaba’s T-Head semiconductor division designed the XuanTie C910 as a high-performance, 12-stage out-of-order 64-bit RISC-V processor core. Engineered to compete directly with contemporary Arm Cortex-A73 and Cortex-A76 cores, the C910 incorporates aggressive superscalar execution structures: 4-wide instruction decode, an out-of-order execution window supported by a 128-entry Reorder Buffer (ROB), multiple arithmetic logic units, and dual memory access ports.

To accelerate scientific computing, computer vision, and neural network inference, the C910 integrates an aggressive 128-bit Vector Processing Unit compliant with the draft RISC-V Vector (RVV 0.7.1) extension. The vector engine features dual 128-bit execution pipes capable of processing simultaneous vector integer and floating-point SIMD arithmetic.

Standard vs. Vector Memory Execution Pipelines

In the scalar execution pipeline of the C910, standard integer load and store instructions (such as ld, sd, lw, and sw) route through the conventional Load-Store Queue (LSQ). The scalar LSQ rigorously queries the L1 Data Translation Lookaside Buffer (32-entry fully associative DTLB), falls back to the 1024-entry 4-way set-associative L2 TLB on misses, checks the Page Table Entry permissions, verifies that \(U=1\), and halts execution if an unprivileged process targets kernel memory.

However, to maximize throughput and minimize vector memory latency during high-bandwidth SIMD operations, the C910 design team implemented a dedicated, high-speed Vector Load-Store Unit (VLS) connected directly to the system L2 cache crossbar and the outer AXI4 system bus.

Due to an RTL logic flaw in the microarchitectural address validation state machine, certain non-standard or custom vector memory operations (specifically vector store instructions executing with specific address configurations and vector register lengths) completely bypass the MMU and TLB translation pipeline!

The Physical Memory Protection (PMP) Bypass

In RISC-V architecture, security does not rely solely on the MMU. The specification mandates Physical Memory Protection (PMP). PMP consists of dedicated Machine-mode Control and Status Registers (such as pmpcfg0–pmpcfg3 and pmpaddr0–pmpaddr15) that establish hard physical address boundaries. PMP is designed precisely as a defense-in-depth safety net: even if an MMU fails or software executes in physical addressing mode, PMP checks every physical memory access against locked physical ranges.

Catastrophically, the XuanTie C910’s Vector Load-Store Unit was physically routed around the PMP checker hardware logic as well. The vector memory unit issues AXI bus requests directly to the L2 cache controller and memory bus, completely ignoring both the MMU page table permissions and the PMP hardware comparison matrix!

3. The GhostWrite Exploit: Total Root Takeover in Under 100 Milliseconds

Because GhostWrite is an architectural write primitive rather than a speculative timing side-channel, exploitation is 100% deterministic, noiseless, and blindingly fast.

In transient side-channels like Spectre, Meltdown, or Zenbleed, an attacker must prime the CPU cache, execute speculative code branches, measure clock cycles with high-resolution timers, and statistically infer leaked bits through noise. The leakage rate is typically a few kilobytes per second. GhostWrite, by contrast, gives the attacker a high-bandwidth 128-bit physical write portal running at memory bus speeds.

In their academic disclosure, the CISPA researchers demonstrated that an unprivileged local user (or malicious untrusted Docker container) can achieve complete, unrestricted root takeover of a Linux RISC-V system through a simple three-step sequence:

1. Physical Address Probing: Linux kernel physical memory layout is predictable or easily mapped via /proc/iomem or low-entropy physical memory probing. The base physical address of the kernel code segment or system page tables is located in microseconds.
2. Direct Kernel Page Table Modification: The attacker issues a single vector store instruction targeting the physical memory address of the current process’s Page Table Entry. By overwriting the PTE permissions to grant User-mode read/write access to kernel memory, the attacker grants themselves universal access.
3. Credential Structure Overwrite: Alternatively, the attacker locates the kernel’s struct cred array in physical RAM and modifies their process credentials:
   $$\text{cred}\rightarrow\text{uid} = 0, \quad \text{cred}\rightarrow\text{gid} = 0, \quad \text{cred}\rightarrow\text{euid} = 0$$

   Within 80 milliseconds, the unprivileged userspace shell instantly promotes to UID 0 (root), with all security modules (SELinux, AppArmor) bypassed without generating a single system log event.

Proof-of-Concept Assembly Mechanics

The exploit code required to trigger GhostWrite is remarkably compact. An unprivileged C or assembly program needs only to configure the vector execution registers using the RISC-V vector configuration instruction vsetvli, load malicious data (such as null bytes or supervisor permissions) into vector register v0, and execute the errant vector store instruction pointing to the target physical memory address:

On a compliant CPU, executing vse64.v with a kernel address from userspace immediately triggers a fatal page fault. On the XuanTie C910, the instruction completes without error, instantly overwriting kernel memory with the contents of v0.

4. Hardware Ecosystem Blast Radius: Impacted Commercial SoCs

Unlike theoretical university silicon exploits that only affect experimental FPGA soft-cores or laboratory test chips, the XuanTie C910 was licensed widely and deployed across massive commercial hardware production runs:

In cloud deployments hosting multi-tenant workloads on SG2042 servers, GhostWrite completely breaks cloud hypervisors (KVM, Xen). A rogue tenant renting an unprivileged virtual machine can execute vector store instructions to write directly into the host hypervisor’s memory or steal data from neighboring customer VMs running on the same server chassis.

5. Exploit Comparison: GhostWrite vs. Spectre vs. Rowhammer

To understand why GhostWrite has sent shockwaves through the semiconductor security community, consider how it compares to other notorious hardware vulnerabilities:

6. The Crushing Mitigation: Disabling the Vector Engine in Linux

Because the XuanTie C910 is an ASIC design lacking re-programmable microcode ROM patches for its execution pipelines, GhostWrite cannot be patched in silicon. The defect is permanently etched into the copper interconnects and silicon gates of millions of manufactured chips.

This left the Linux kernel development team and OS maintainers with an agonizing choice:

Kernel-Level Vector Disabling

The only method to secure a vulnerable system is for the operating system kernel to completely disable hardware vector extensions. In Linux, this is achieved by clearing the vector status bits in the machine status register (mstatus.VS = 00) during boot:

Whenever any userspace process attempts to execute a vector instruction, the core raises an illegal instruction trap, preventing the vulnerable pipeline from ever executing.

The Performance Destruction: Empirical Workload Benchmarks

While disabling vector processing successfully protects the system from root takeover, the performance destruction is catastrophic. The table below illustrates the empirical throughput collapse across standard server and AI workloads on the 64-core Sophgo SG2042 processor when vector extensions are deactivated:

Users who purchased 64-core RISC-V workstations specifically for high-throughput AI and multimedia development are left with systems running at a fraction of their advertised computational capability. While general-purpose web serving remains largely unaffected because it relies on scalar integer instructions, compute-intensive workloads that justified the hardware purchase suffer massive throughput penalties.

7. Institutional FAQ: GhostWrite Hardware Vulnerability Q&A