How Secure Are Commercial RISC-V CPUs?
- Track: RISC-V
- Room: H.2214
- Day: Saturday
- Start: 16:40
- End: 17:15
- Video only: h2214
- Chat: Join the conversation!
The last decade of CPU vulnerabilities has shown how microarchitectural performance optimizations can undermine isolation. Transient execution attacks like Meltdown and Spectre exposed deep flaws in x86 CPUs. RISC-V, by contrast, enters with the promise of simplicity and transparency—a clean slate. Yet the question remains: will we repeat the same mistakes, or can we design a secure architecture from the start?
This talk takes a critical look at how RISC-V implementations handle microarchitectural security today. We show that even "simple" in-order designs already suffer from architectural flaws and powerful side channels. In our earlier work, we demonstrated novel attacks, such as Cache+Time and CycleDrift, on the first commercial RISC-V CPUs, exploiting unprivileged access to instruction-retirement counters and cache-timing leakage.
But manual analysis does not scale. RISCover, our open-source differential fuzzing framework, automatically discovers architectural vulnerabilities across closed-source RISC-V CPUs. By comparing instruction behavior across 8 commercial CPUs from 3 vendors, RISCover found what manual analysis missed: GhostWrite, a bug in T-Head's XuanTie C910 that lets unprivileged code write directly to physical memory, completely bypassing virtual memory isolation. We also discovered multiple "halt-and-catch-fire" sequences that crash CPUs from userspace, leading to denial-of-service.
These findings reveal a pattern: while the RISC-V specification provides strong security primitives (e.g., PMP and cleaner privilege separation), implementations consistently choose insecure defaults—leaving unprivileged timing sources enabled, shipping undocumented vendor extensions like XTheadVec without proper validation, and omitting features to limit speculation. RISC-V is at an inflection point: the architecture is still young enough to fix, but adoption is accelerating fast. The decisions vendors make today—insecure defaults, unvalidated extensions, missing mitigations—will be baked into billions of chips we cannot patch.
Speakers
| Fabian Thomas | |
| Lukas Gerlach |