Black Hat Computer security researchers at the CISPA Helmholtz Center for Information Security in Germany have found serious security flaws in some of Alibaba subsidiary T-Head Semiconductor's RISC-V processors.

The most serious of these, which affects the four T-Head C910 CPU cores in the TH1520 SoC, has been dubbed GhostWrite because it allows a rogue application or user to read and write physical memory, and execute arbitrary code with kernel (supervisor) and machine-mode privileges, allowing them to take over the device entirely.

The threat scenario assumes the attacker is unprivileged but capable of executing native code on affected hardware. Thus it would apply to malware that gets onto a vulnerable system, and customers running virtual machines or containers on vulnerable hardware, allowing them to fully hijack the host, but not to a remote attacker.

The vulnerability lies in faulty instructions in the C910's vector extension implementation, added to allow the processing of larger data values and specific to that CPU design. The problem is that some of these instructions operate on physical memory rather than virtual memory, which undoes whatever isolation is in place to keep the operating system and applications separate.

Yes, that's right: When you use these flawed instructions, you will be touching physical memory directly, bypassing the MMU and its memory protection mechanisms that ordinarily prevent apps from interfering with each other and the underlying OS and hardware.

And as the instructions are baked into the silicon, they cannot be fixed with a microcode or software update. To mitigate the issue, the vector extension must be disabled. Doing so means applications relying on those vector instructions will break, and if emulated in software to continue working, will suffer punishing performance hits.

The researchers who spotted all of this - Fabian Thomas, Lorenz Hetterich, Ruiyi Zhang, Daniel Weber, Lukas Gerlach, and Michael Schwarz - are scheduled to present their findings at the Black Hat security conference in Las Vegas, Nevada, on Wednesday.

They've also published a website, ghostwriteattack.com, and a technical paper titled, "RISCVuzz: Discovering Architectural CPU Vulnerabilities via Differential Hardware Fuzzing."

RISC-V is an open standard instruction set architecture (ISA). Unlike other more widely used ISAs, such as x86 and Arm, it is available on a royalty-free basis and anyone is welcome to contribute to it.

Chip designers can take the ISA's specifications and use them to design their own RISC-V-compatible CPUs, and can choose to support optional extensions to add functionality to their cores. Thus the security issues here with the C910 lie with T-Head's own implementation of the ISA, specifically its non-standard implementation of the vector extension, and not the specs themselves nor other RISC-V chips.

This openness and extensibility has made RISC-V popular among vendors, the CISPA Helmholtz boffins observe in their paper. But the result has been a growing range of hardware implementations with varying features and security measures - and their own security failings.

To better assess chip behavior and characteristics, the researchers developed a fuzzing framework called RISCVuzz, which uses a variety of RISC-V implementations to perform differential fuzzing. The testing tool assumes that the architectural result of each instruction should be the same across different CPUs and flags instances where behavior is different.

The researchers used RISCVuzz on five currently available RISC-V CPU core designs running 64-bit Linux: T-Head XuanTie C906/C908/C910, and SiFive U54/U74. They found three architectural CPU vulnerabilities within the T-Head chips, not to mention other bugs that cause segmentation faults in the two latest major versions of QEMU.

The most severe vulnerability, GhostWrite, affects the C910 in the TH1520 SoC and lets unprivileged users write anything to memory without concern for security and isolation features.

"The attack is 100 percent reliable, deterministic, and takes only microseconds to execute," the GhostWrite website explains. "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."

Exploiting it is as simple as running the following instruction sequence:

vsetvli zero, zero, e8, m1
vmv.v.x v0, a0
vse128.v v0, 0(t0)

Where the register t0 holds the physical memory address you want to write to, even if you're not allowed to do so, and a0 the byte you want to write; and it just happens. T-Head's implementation of its non-standard vse128.v instruction is broken in that it doesn't treat the address as a virtual one, and instead goes straight to physical memory, allowing any application, including malware, to scribble over the OS kernel, or machine-level hypervisor or firmware, and take over the device.

Additionally on the C910, reading from virtual address 0 if it's backed by physical RAM freezes the CPU core regardless of privilege level until a power-cycle. Sheesh.

It reminds us of Intel's 1990s-era F00F bug that would lock up the processor until a hard reboot, among other chip errata over the years from the industry.

There are also two vulnerabilities affecting the T-Head XuanTie C906 and C908 described in the paper as halt-and-catch-fire CPU vulnerabilities. They allow an unprivileged attacker to crash the CPU. These bugs, if exploited, would require a restart.

The paper lists off other failings in T-Head's designs, such as instructions faulting as illegal when they shouldn't, or generating the wrong kind of exception.

The C910-based TH1520 SoC is used by French cloud Scaleway.

The following devices are also said to be vulnerable to the C910's GhostWrite:

• Lichee Cluster 4A, compute cluster
• Lichee Book 4A, laptop
• Lichee Console 4A, tiny laptop
• Lichee Pocket 4A, gaming console
• Sipeed Lichee Pi 4A, single-board computer (SBC)
• Milk-V Meles, SBC
• BeagleV-Ahead, SBC

The boffins in their paper observe that Shandong University in China has a RISC-V cluster with a C910 variant, though they've been unable to determine whether that variant is affected.

Fixing these bugs isn't easy. As we said, the only mitigation proposed for GhostWrite is disabling the faulty vector extension. As the authors explain, this breaks applications using vector instructions and adds an overhead of 77 percent, as measured by rvv-bench.

"For the C906 CPU-halting bug, we find no mitigation since the responsible vendor extension cannot be disabled," the paper says.

The researchers say they disclosed their findings to Alibaba's T-Head which has acknowledged and reproduced the C910 and C906 bugs, though has yet to respond to the C908 report.

Michael Schwarz, faculty at the CISPA Helmholtz and one of the paper's co-authors, told The Register, "Scaleway notified users of their RISC-V instances, suggesting to update the kernel due to security vulnerabilities. This is something the users have to do manually. As far as I know, this kernel update disables the vector extensions."

Ironically, it's the "reduced instruction set" nature of RISC-V implementations that limits options for workarounds, because today's generally available RISC-V processors, as far as we're aware, don't use reprogrammable microcode to operate - meaning it's not possible to load an update at runtime to correct broken instructions and add functionality.

"The complexity of the x86 ISA requires a 'firmware' layer (ie, the microcode) to support some of the very complex instructions," explained Schwarz. "A side effect of that is that the behavior of such instructions can also be changed with a microcode update. Additionally, microcode updates allow introducing new features to work around vulnerabilities.

"We have seen that for vulnerabilities on Intel CPUs, such as ZombieLoad: A microcode update added a new feature to flush internal buffers. While this did not fix the vulnerability, it made sure that there was no secret data left to leak.

"RISC-V only has simple instructions that do not require such a 'firmware' layer. Thus, there is also no possibility to add new features via an update. However, it would be possible to also have microcode on RISC-V but I'm not aware of any RISC-V CPU implementing that."

But that's something Schwarz and his co-authors recommend in their paper, based on the assumption that the unregulated use of the RISC-V ISA and the possibility of custom vendor extensions will lead to more vulnerabilities of this sort.

"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," the paper concludes. ®

https://www.theregister.com//2024/08/07/riscv_business_thead_c910_vulnerable/