Answers are grounded in this paper and cite their sources.
Scoping review analyzes RISC-V exception handling vulnerabilities, indicating necessary defenses and implications.
RISC-V’s open and extensible design improves flexibility, but it also permits vendors to customize trap behavior and reserved opcode space in ways that can affect exception handling. This paper presents a scoping review of RISC-V exception-handling security, focusing on how traps, privilege transitions, control registers, and handler routines can become attack surfaces when they are not correctly protected. We organize the literature by a five-stage exception lifecycle and map documented attacks and defenses to the architectural state they affect. Our review shows that exception-handling vulnerabilities arise from exposed control registers, insufficiently protected trap entry and return paths, and flawed handler execution. Recent attacks, such as GhostWrite, halt-and-catch-fire conditions, and side-channel exploits, illustrate how weaknesses in exception management can lead to privilege escalation, denial of service, or data leakage. In contrast, defenses are unevenly distributed across the lifecycle: backward-edge return-time integrity is addressed by multiple dedicated mechanisms, while dispatch-time and privilege-transition protection remain largely indirect and are often embedded within broader trusted-execution designs. Because the primary studies report heterogeneous cost metrics, the overhead values we extract are presented as reported rather than normalized across a common benchmark. The literature suggests that lightweight mechanisms, such as Physical Memory Protection and software-based control-flow enforcement, generally incur modest overhead, whereas stronger approaches, such as CHERI-RISC-V and Trusted-Execution Environments, may impose substantially higher costs on exception-heavy workloads. Overall, our findings indicate that exception handling should be treated as a security-critical boundary and that future work should emphasize stage-specific defenses, formal verification, and tighter integration between hardware and software protections.
No takes yet. Share an insight, caveat, or question.
Siapoush et al. (2026) studied this question.
Synapse has enriched 10 related papers. Consider them for comparative context: