RISC-V Isn't Immune to Microarchitectural Attacks

TLDR: Researchers at CISPA have demonstrated that RISC-V architectures, despite being open-source, remain vulnerable to classic microarchitectural side-channel attacks like Spectre and Flush+Reload. By exploiting unprivileged performance counters and shared resources, they successfully leaked data from inaccessible memory regions on Allwinner D1 and SiFive U74 cores. This research proves that open-source hardware design does not inherently solve the security flaws that have plagued proprietary CPUs for years.

Hardware security has long been treated as a black box, a domain where proprietary vendors held all the cards and researchers were left to guess at the underlying implementation. The rise of RISC-V promised a shift toward transparency, where the ability to inspect the RTL and verify the design would theoretically lead to more secure silicon. However, recent research presented at Black Hat 2023 by the RootSec group at CISPA shatters the illusion that open-source hardware is a silver bullet for microarchitectural vulnerabilities.

The Reality of RISC-V Vulnerabilities

The core of the problem lies in the fact that microarchitectural side-channel attacks are not bugs in the traditional sense. They are fundamental consequences of how modern, high-performance processors are designed to optimize execution speed. When you build a CPU that uses branch prediction, speculative execution, and shared caches to squeeze out every possible cycle of performance, you inevitably create timing differences that an attacker can measure.

The researchers focused on two specific RISC-V implementations: the Allwinner D1 and the SiFive U74. Their work demonstrates that these processors are susceptible to the same classes of attacks that have affected Intel and AMD chips for years. The open-source nature of the ISA and the core design allows for white-box bug hunting, but it does not automatically result in a hardened, secure product.

Exploiting Performance Counters

One of the most concerning findings is the presence of unprivileged performance counters on these RISC-V cores. Performance counters are intended to help developers benchmark and optimize their code, but they are a goldmine for an attacker. By monitoring events like cache misses or instructions retired, an attacker can infer what a victim process is doing without needing direct access to that process's memory.

On the tested RISC-V hardware, these counters are accessible from user space. This is a design choice that directly enables side-channel attacks. For instance, an attacker can use these counters to bypass KASLR (Kernel Address Space Layout Randomization) by timing how long it takes for the CPU to handle specific instructions or by observing the frequency of branch-taken events.

To reproduce this, an attacker doesn't need complex hardware. A simple user-space program can read these counters to build a profile of the system's execution flow. The following pseudo-code illustrates how one might access these counters on a vulnerable RISC-V system:

// Accessing performance counters on RISC-V
uint64_t read_perf_counter() {
    uint64_t val;
    asm volatile ("rdcycle %0" : "=r" (val));
    return val;
}

Moving Beyond Simple Side-Channels

While cache-based attacks like Flush+Reload are well-understood, the researchers pushed further by demonstrating a new variant they call "Flush+Fault." This technique is particularly effective because it doesn't rely on shared memory between the attacker and the victim, which is a common prerequisite for traditional Flush+Reload attacks.

Instead, the attacker forces the CPU to speculatively execute code that triggers a fault. By measuring the time it takes for the CPU to handle this fault, the attacker can determine whether a specific memory address was cached. This effectively turns the CPU's own error-handling mechanism into a side-channel. This is a significant escalation because it removes the requirement for the attacker to have a shared library or memory segment with the victim.

The Defensive Challenge

Mitigating these attacks is notoriously difficult because they are baked into the performance-oriented design of the processor. For defenders, the primary strategy is to restrict access to the telemetry that makes these attacks possible. In the case of performance counters, the fix is straightforward: move the interface behind a wall of privilege. Only the kernel should have access to these counters, effectively preventing user-space processes from using them to spy on other parts of the system.

However, this is only a partial solution. As long as CPUs prioritize speed through speculative execution and shared resources, new side-channels will continue to emerge. The OWASP Side-Channel Attack documentation provides a good overview of why these vulnerabilities are so persistent.

What Comes Next

The shift toward RISC-V is inevitable, but we must stop assuming that "open" means "secure." The research from CISPA shows that we are simply porting the same architectural flaws into a new ecosystem. If we want RISC-V to be the foundation of a more secure future, we need to move security research from the software layer down to the RTL.

For those of you working in security research or penetration testing, this is a call to action. The CISPA RootSec GitHub repository contains the code used in their experiments. Start by analyzing these implementations. If you are involved in hardware design, prioritize security-by-design over raw performance metrics. We have the opportunity to build a better foundation, but only if we acknowledge that the current approach to microarchitectural optimization is fundamentally broken.