MIND THE GAP: SECURING PRIVILEGE TRANSITION

About KMSEC

KMSEC (Pty) Ltd. is a specialized cybersecurity research and consulting firm dedicated to securing the next generation of scalable, impactful systems and services. We perform academic quality research and industry informed analysis of low-level software and hardware in order to provide cutting-edge risk analysis to our clients.

Document Attribution & Metadata

AI Usage Policy

The following white paper contains text imagery and formatting that was partially generated by KMSECs AI enhanced publishing tools. Understanding the risk in producing false referencing, nonsensical language and low quality text KMSEC ensures that: (i) our media output is heavliy proof read and scrutenized before release (ii) continously improved with attributed and tracked changes and (iii) as an organization we are approachable regarding the quality of our content. Please enjoy the following whitepaper and please contact us for queires or more details on the research subject.

Copyright

© 2026 Keith Makan Security Consultancy (KMSEC). All Rights Reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means without the prior written permission of KMSEC.

1. Abstract

Securing bootloaders is a complex art and involves more than the cryptographic verification of firmware binaries. In modern architectures like ARM (TrustZone), RISC-V, and x86_64, failure to rigorously sanitize state, explicitly lock down physical memory configurations, and clear critical CPU registers before executing an environment transition opens a plethora of attack vectors. Furthermore, the microarchitectural state—branch target buffers, cache hierarchies, and translation lookaside buffers—must be explicitly neutralized to prevent speculative side channels from bridging the privilege gap. This white paper examines the structural risks involved in privilege transition boundaries, summarizing some aspects of recent academic literature and industry knowledge regarding secure enclaves, microarchitectural leakage, and concurrency threats. The white paper closes by providing concrete assembly-level guidance and some best practices for engineers implementing secure exception returns across major architectures, establishing a disciplined baseline for secure firmware handoffs.

Key Contributions

This paper systematically addresses the structural risks of architectural context switches by providing the following key contributions:

• Comprehensive background and introduction to the subjects of privilege levels and ISAs.
• Covers the 3 most popular ISAs: Examines the privilege models and boundaries across ARM, RISC-V, and x86_64.
• Analysis of contemporary vulnerabilities exemplifying the need to sanitize state: Explores threats such as microarchitectural FPU/SIMD state leakage (e.g., LazyFP) and compiler-induced stack leakage.
• Analysis of academic studies that also analyze the problem of secure privilege transition showing some of the approaches: Summarizes recent literature to highlight vulnerability patterns and automated verification methodologies.

2. Introduction

Bootloaders fundamentally operate as privilege demotion engines. A system powers on at the highest possible execution tier, possessing unfettered access to all physical memory, peripheral buses, and one-time programmable (OTP) security fuses. As the Chain of Trust (CoT) matures and hands off to increasingly complex software environments, it must systematically shed these privileges.

Switching to lower contexts comes with the responsibility of preparing the environment so that lower-privileged execution doesn't inherit too much functionality or information. This requires a choreographed dance and is not merely a transfer of execution flow; it is the foundational mechanism that establishes memory isolation via hardware-enforced security policies—such as RISC-V Physical Memory Protection (PMP)[ 9] and ARM TrustZone address space controllers—and permits the safe execution of untrusted code.

However, the exact moment of this context switch creates a perilous temporal window where the departing privileged state and the arriving untrusted state briefly intersect—a vulnerability vector demonstrated by microarchitectural FPU/SIMD state leakage flaws like LazyFP (CVE-2018-3665)[ 3] or compiler-induced TrustZone stack leakage (CVE-2024-7883). Failing to rigorously sanitize the environment during this transition unravels the entire secure boot architecture, rendering the staged sandbox completely compromised from inception.

The following white paper enumerates some of the contemporary research which is impactful on the concept of secure privilege level switching in RISC-V, ARM64, and x86_64 Instruction Set Architectures (ISAs). We will cover some basic background in the concepts of privilege levels, discuss the common pitfalls, and look at some bad and good examples of implementations.

To ground this evaluation, the next section establishes the core architectural models and explicit privilege states governing these transitions across major ecosystems.

3. Understanding ISAs

Before examining the specific privilege models and security boundaries that govern modern processors, it is essential to establish the foundational concept of an Instruction Set Architecture (ISA). An ISA serves as the abstract boundary—a strict architectural contract—between the hardware and the software. It defines the supported data types, the register state, the addressing modes, the memory architecture, and the precise set of assembly instructions (opcodes) that a processor can execute. From a software perspective, the ISA is the specification of what the hardware promises to do when executing a given program.

The three prominent architectures analyzed in this paper—x86_64, ARM, and RISC-V—originated from distinct design philosophies, periods, and organizational drivers:

• x86 (and x86_64): Originally introduced by Intel in 1978 with the 16-bit 8086 processor, x86 was designed to enable the transition from 8-bit to 16-bit personal computing. It is the canonical example of a Complex Instruction Set Computer (CISC) architecture, which grew through decades of backward-compatible extensions. In 2003, AMD introduced the 64-bit extension (x86_64 or AMD64), which became the industry standard for desktop, laptop, and enterprise server environments.
• ARM (Advanced RISC Machines): Developed in the mid-1980s by Acorn Computers (with the ARM1 designed between 1983 and 1985 by Sophie Wilson and Steve Furber), ARM was started to create a high-efficiency, cost-effective RISC (Reduced Instruction Set Computer) processor for Acorn's personal computers. Spun off as an independent licensing entity (Arm Ltd.), its focus on energy efficiency and power optimization has made it the dominant architecture for mobile devices, embedded systems, and increasingly, high-performance data centers.
• RISC-V: Started in 2010 at the University of California, Berkeley, by Krste Asanović, Andrew Waterman, Yunsup Kar, and David Patterson, RISC-V was created as an open, royalty-free, and modular RISC instruction set. Unlike proprietary ISAs, RISC-V is extensible and free from licensing constraints, managed by RISC-V International, and designed to support everything from microcontrollers to supercomputers through standard base sets and optional modular extensions (e.g., Vector, Compressed, Floating Point).

While each of these ISAs emerged from different technological eras and design philosophies, they all eventually faced the necessity of rigorously defining how software interacts with hardware resources. As processors grew more complex, simply providing a list of computational instructions was no longer sufficient. To securely manage modern hardware, architectures had to formally delineate between the instructions available to everyday applications and the highly privileged mechanisms required to govern the system itself. This fundamental split gives rise to two distinct profiles within any modern ISA.

The following section explains the two profiles of specifications for each of these ISAs.

3.1 Application-Level vs. System-Level Specifications

Modern architecture reference manuals partition their specifications into two distinct conceptual profiles, reflecting the partition of software responsibilities:

• Application-Level Specification: This defines the unprivileged environment visible to user-space application software. It outlines the programmer's model for standard computation: the general-purpose registers (such as x0–x31 in RISC-V or RAX–R15 in x86_64), floating-point/vector registers, and basic computational instruction sets (arithmetic, logic, control flow). The primary goal is application portability across different CPU implementations of the same ISA.
• System-Level (or Privileged) Specification: This defines the resources and mechanisms required to boot, manage, partition, and secure the CPU. It governs exception levels and privilege modes, system Control and Status Registers (CSRs), page table structures for virtual memory translation (MMU configuration), interrupt handling, physical memory protection (e.g., RISC-V PMP), and security isolation domains (e.g., ARM TrustZone).

Understanding this division is critical for Low-Level and Firmware Security. While application-level software operates under the assumption of a pre-configured, isolated sandbox, it is the system-level architecture that enforces the security boundaries. Privilege transition (demoting from a secure boot state or elevating on a system call) is inherently a system-level event. As research by Reid has shown, system-level specifications are highly complex, and formal validation is required to ensure that context switches do not leak state between application and system execution profiles. Without proper sterilization of the microarchitectural and architectural state, the boundaries defined by the system-level specification can be bypassed by unprivileged software.

The following section explores the architectural models of three major ISAs: x86_64, ARM, and RISC-V and sets the background for discussing more vulnerabilities that introduce violations and privilege bypasses.

4. Architectural Privilege Models

Across modern instruction set architectures (ISAs), a privilege level is defined by the specific subset of registers, memory regions, and hardware functionality exposed to executing software, establishing strict pathways for voluntary privilege reduction (demotion) and involuntary privilege escalation (promotion). ISA designers provide guidance for implementing this according to the way hardware understands instruction idiosyncrasies. For instance, RISC-V may specify that an mret instruction transitions privilege levels, but the clearing of the L2 cache, general-purpose registers, or internal state is implementation-specific. Consequently, low-level software must orchestrate these transitions carefully according to the system-level architecture specifications.

Common to each ISA included here is (i) privilege levels which have full access to functionality and physical addressing which is traditionally intended to run the bootloader at device start up (ii) instructions which promote and demote operational privilege level. (iii) Interrupts and traps which can transition between privilege levels as well. Every source of complexity introduces more of an attack surface for privilege escalation. Later in the paper we will see how each aspect which could impact privilege level implementation has with examples for memory usage, register handling and interrupt design.

The following diagram illustrates the commonalities and how levels are defined to some extent.

Another important caveat that should be noted is the delta between memory behaviour and ISA specification. Namely, where you place specific reset vectors, user space traps etc. and which memory ranges are mapped to specific functionality and/or accessible during given privilege levels is implementation specific: the specification may prescribe semantics for a given memory range but whether this is grounded in truth is specific to your implementation and environment.

The following sections summarize novel aspects of each ISA's privilege architecture expanding on what could not be included or represented in the diagrams.

4.1 RISC-V

RISC-V defines a modular privilege hierarchy consisting of Machine Mode (M-mode), Hypervisor Mode (H-mode), Supervisor Mode (S-mode), and User Mode (U-mode). M-mode serves as the ultimate hardware Root of Trust, possessing unconstrained access to all Control and Status Registers (CSRs) and the entire physical memory range. M-mode firmware directly configures core machine state via CSRs including mstatus (global status and previous privilege tracking), mtvec (trap vector base), mepc (exception program counter), mcause, and mscratch. Crucially, M-mode establishes hardware memory boundaries using Physical Memory Protection (PMP) registers (pmpcfg0–pmpcfg15 and pmpaddr0–pmpaddr63), which enforce read, write, and execute permissions on physical address ranges for lower modes.

S-mode operates beneath M-mode to host operating system kernels. It relies on page-based virtual memory managed via the Supervisor Address Translation and Staging Register (satp), which holds the root physical page frame number for translation schemes such as Sv39, Sv48, or Sv57. S-mode code can access supervisor CSRs (sstatus, sepc, scause, stvec, sscratch) and virtual memory addresses mapped with the User bit set to zero (U=0). When the Hypervisor (H) extension is active, H-mode introduces a two-stage virtual memory translation scheme managed by hgatp alongside hypervisor-specific CSRs (hstatus, hedeleg, hideleg) and background guest supervisor CSRs (vsstatus, vsepc, vsatp), expanding the state space that must be sanitized during context switches.

U-mode represents the unprivileged application tier. Execution in U-mode is strictly confined to general-purpose registers (x0/zero through x31), floating-point registers (f0–f31 and fcsr), and vector registers (v0–v31). U-mode can only access virtual memory pages explicitly designated with U=1 in the page tables and cannot directly read machine or supervisor CSRs. Unprivileged access to hardware performance counters (cycle, time, instret) is gated by M-mode/S-mode counter-enable registers (mcounteren / scounteren).

4.2 ARM (AArch64)

The ARM AArch64 execution environment relies on four distinct Exception Levels (EL0 through EL3), defined in the system-level specifications. Privilege demotion moves downward from EL3 to EL0, while exception promotion traps upward. EL3 runs the Secure Monitor and early firmware, controlling global system partition routing through the Secure Configuration Register (SCR_EL3). EL3 has unrestricted access to physical memory across both the Secure World and Non-Secure World address domains, managed via TrustZone Address Space Controllers (TZASC) or Granule Protection Tables (GPT) in ARM Realm Management extensions. System registers unique to EL3—such as SCTLR_EL3, CPTR_EL3, TTBR0_EL3, VBAR_EL3, and ELR_EL3—dictate global architectural behavior and trap handling.

EL2 hosts hypervisors and virtual machine monitors, controlling stage-2 address translation via the Virtualization Translation Control Register (VTCR_EL2) and Virtualization Translation Table Base Register (VTTBR_EL2). System registers such as HCR_EL2 (Hypervisor Control Register) allow EL2 to intercept traps, virtualize interrupts, and route system calls from lower levels.

EL1 hosts traditional operating system kernels (Non-Secure EL1) or Secure OS enclaves (Secure EL1). Virtual memory at EL1/EL0 is split into two distinct 64-bit Virtual Address (VA) ranges:

• Lower VA Space ($0x0000\_0000\_0000\_0000$ to $0x0000\_7FFF\_FFFF\_FFFF$): Translated via Translation Table Base Register 0 (TTBR0_EL1), intended for user-space applications.
• Upper VA Space ($0xFFFF\_8000\_0000\_0000$ to $0xFFFF\_FFFF\_FFFF\_FFFF$): Translated via Translation Table Base Register 1 (TTBR1_EL1), reserved strictly for kernel execution.

EL0 is the unprivileged user application tier. EL0 code operates exclusively within the lower VA range translated by TTBR0_EL1. It has direct access to general-purpose registers (x0–x30, sp_el0), 128-bit SIMD/Floating-Point registers (v0–v31, fpsr, fpcr), and the Program Counter (PC). Access to system control registers is blocked; unprivileged thread ID registers (such as TPIDR_EL0) or virtual timer registers (e.g., cntvct_el0) are accessible only if explicitly enabled by EL1 via the Kernel Trap Control Register (CNTKCTL_EL1).

4.3 x86_64

The x86_64 architecture enforces privilege separation using protection rings alongside System Management Mode (SMM, historically referred to as "Ring -2"). SMM operates beneath the operating system and hypervisor, executing inside a dedicated physical memory region called System Management RAM (SMRAM). SMRAM ranges are hardware-locked by chipset controllers (e.g., TSEGMB / SMRAMC). Upon receiving a System Management Interrupt (SMI), the CPU saves its complete architectural state into an SMRAM State Save Area and executes unmapped SMM code with full access to physical memory and Model-Specific Registers (MSRs) via rdmsr and wrmsr instructions. Exiting SMM via RSM restores state directly from this Save Area.

Ring 0 is the supervisor privilege tier used by OS kernels. Ring 0 has complete control over system Control Registers:

• CR0: Controls Protection Enable (PE), Paging Enable (PG), and Write Protect (WP).
• CR3: Points to the base physical address of the 4-level or 5-level page table hierarchy (PML4 / PML5).
• CR4: Enables hardware security features including Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), User-Mode Instruction Prevention (UMIP), and OSXSAVE.

Ring 3 represents the unprivileged user space. Execution is limited to 64-bit general-purpose registers (RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, R8–R15), 128/256/512-bit vector registers (XMM0–XMM15 / YMM / ZMM, MXCSR), and user segment selectors (CS, DS, SS, ES, FS, GS). Virtual memory access is strictly restricted to page table entries marked with the User/Supervisor bit set to User (U/S = 1). Direct I/O port instructions (IN / OUT) are prohibited unless explicitly permitted by the TSS I/O Permission Bitmap, and attempts to execute privileged instructions (e.g., cli, hlt, wrmsr, lgdt) trigger a General Protection Fault (#GP).

4.4 Summary of Architectural Boundaries

The table below summerizes the explicit privilege states, critical control registers, and memory scope defining hardware-enforced isolation across the three primary architectures.

Having outlined these structural boundaries and architectural behaviors, the following section transitions to examining how adversaries exploit gaps in these models through microarchitectural and concurrency threat vectors.

5. Threat Modeling ISA Implementations

When modeling threats against ISAs implementaitons, we must evaluate vulnerabilities across the entire lifecycle—from initial hardware design through compilation and final software execution.

The transition from a theoretical specification to a physical chip and eventually to running software introduces multiple layers of risk. Pre-silicon threats originate during the RTL design[20] and physical layout phases, potentially baking in hardware trojans, logic flaws, or physical side-channel susceptibilities that can be systematically evaluated using (i) RTL Code and design based Security Assessments (ii) Symbolic analysis and other automation and emulation frameworks. Compiler threats compromise the translation of secure source code into machine code, either through aggressive optimizations that remove security checks or via supply chain attacks like fake compiler injects. Defending against compiler misuse and potentially malicious behaviour means subjecting binary output and source code input as well as supporting arifacts to rigourous security review via (i) Source Code Reviews (ii) Firmware Binary Reverse Engineering and (iii) Fuzz and Stress testing. Post-silicon Threats encompass the regular software implementation problems and microarchitectural side-channels that manifest after the hardware is finalized and deployed. The severity of the gap between theoretical models and finalized hardware is underscored by automated evaluation tools like RISCover, which systematically discover user-exploitable architectural security vulnerabilities in closed-source RISC-V CPUs, highlighting how pre-silicon design oversights inevitably surface as post-silicon threats.

The diagram below illustrates these distinct areas of threat.

Furthermore, the physical supply chain introduces a critical dimension of risk. Modern hardware is typically manufactured via a complex network of third parties, dictated by the Bill of Materials (BOM). This fragmented process inherently requires shipping physical boards between different organizations and regions, each exposing the hardware to entirely different risk profiles. For example, a manufacturer might assemble a board, install temporary factory test firmware, and then transit the hardware to a secondary facility for QA testing. If these factory-specific materials—such as diagnostic keys, unprotected test firmware, or unlocked debug interfaces—are not explicitly removed before the transition, downstream testers or bad actors intercepting the shipment could leverage them to skew or bypass the device's authentication mechanisms entirely. Ultimately, supply chain-borne threats carry massive impact; it is not just what the board or bootloader are designed to do, but exactly how they come together across the manufacturing lifecycle that dictates the device's true security posture.

The following section introduces some theory and background on more advanced threat vectors which affect ISAs.

6. Advanced Threat Vectors

Transitioning from static architectural models to active exploitation dynamics, this section analyzes the systemic flaws that emerge when hardware context switches fail to account for hidden state leakage and asynchronous execution windows.

6.1 Microarchitectural Side Channels

Architectural register zeroization is necessary but insufficient. Modern superscalar processors maintain vast amounts of hidden microarchitectural state that persists across privilege boundaries. If the bootloader does not explicitly flush this state, an attacker operating in the lower-privilege domain (e.g., the OS kernel) can extract high-privilege secrets.

• Speculative Execution (Branch Target Injection): Branch Target Buffers (BTBs) predict the destination of indirect branches. If the Secure Monitor (EL3/M-Mode) executes a branch based on a secret, the BTB state is altered. A malicious OS can measure BTB hit/miss rates to infer the secret. Mitigation requires issuing explicit branch predictor invalidation barriers (e.g., BPIALL on ARM) before demotion.
• Cache Timing Channels (Prime+Probe / Flush+Reload): Cryptographic routines in the bootloader leave data footprints in the L1/L2 caches. An attacker executing in the lower-privilege domain measures the access time $\Delta t$ of a shared cache line. If $\Delta t < \tau$ (where $\tau$ is the memory threshold parameter, indicating a cache hit), the attacker infers that the Secure Monitor recently accessed this line, potentially leaking AES or RSA key material. Secure transitions must execute cache invalidation instructions covering all levels of the cache hierarchy.
• Translation Lookaside Buffers (TLB): TLBs cache virtual-to-physical memory mappings. Residual TLB entries from a highly privileged execution state can allow a lower-privileged context to speculatively access secure memory before the MMU fully catches the permission violation, leading to Meltdown-style transient execution attacks.

6.2 Concurrency and Race Conditions

In multicore SoCs, privilege transitions present a precarious window for Time-of-Check to Time-of-Use (TOCTOU) flaws. If Core A drops to S-mode while Core B remains in M-mode processing a shared memory structure, Core A can manipulate the state mid-transaction. Identifying these vulnerabilities manually is notoriously difficult; securing these boundaries typically requires the automated detection of concurrency race conditions in binary programs via symbolic execution, utilizing SMT solvers to map out all possible interleaved execution paths during the bootloader's handover phase. Without rigorous synchronization barriers, asynchronous privilege demotion creates fatal memory corruption primitives.

6.3 Compiler-Induced Architectural Leakage

The complexity of hardware state preservation is frequently exacerbated by compiler behavior during privilege boundaries. A prominent contemporary example is CVE-2024-7883, which affects systems utilizing Arm Cortex-M Security Extensions (CMSE) built with affected LLVM-based toolchains (such as Clang 11 through 19)[ 10]. In these environments, when a Secure to Non-secure function call is executed that returns a floating-point value—and it is the first floating-point use since entering the Secure state—a discrepancy with the CONTROL_S.SFPA flag occurs. This causes the VLSTM instruction to execute as a NOP, failing to clear the registers, while the subsequent VLLDM instruction inadvertently restores up to 64 bytes of Secure stack contents into floating-point registers (S16–S31). This allows Non-secure code to passively extract confidential Secure stack memory. Writeups by Arm[ 10] and Debian emphasize that this vulnerability relies on specific compiler flags (e.g., -mcmse and -mfloat-abi=hard), but it starkly highlights the critical danger of combining automated compiler register handling with TrustZone boundaries.

To contextualize how these vulnerabilities are discovered and cataloged in modern research, the next section details our empirical methodology for sourcing and filtering peer-reviewed firmware security literature.

7. Research Methodology

To systematically evaluate the threat landscape introduced above, this section outlines the rigorous filtering pipeline used to curate the academic literature examined in this paper. We query primary academic databases—specifically Google Scholar and Semantic Scholar—to identify papers discussing implementation challenges surrounding privilege levels, filtering for findings that demonstrate concrete exploitability.

Following this methodology, the subsequent section presents a structured review of selected academic works, examining how automated verification and hardware side-channel studies validate these transition risks.

8. Literature Review

The academic community has increasingly focused on the vulnerability of the security monitor and the hardware isolation layers that bootloaders configure prior to OS handoff. The overarching academic consensus dictates that secure boot loaders must treat the destination environment (e.g., the EL1 OS or U-mode) as explicitly hostile, demanding complete architectural and microarchitectural sterilization.

Automated ISA Analysis and State Verification (Kalani et al.): Recent work by Kalani et al. highlights the sheer complexity of modern ISAs, where security-sensitive state requirements are often scattered across thousands of pages of prose documentation[ 1, 2]. To bridge this gap, they introduced Sailor, a tool that parses machine-readable Sail ISA specifications to automatically compute the precise architectural state that must be saved and restored during context switches[ 1, 2]. The evaluation methodology leveraged the Isla symbolic execution engine to process the RISC-V Sail model, generating comprehensive execution traces. Sailor then applied a novel classification algorithm to these traces to automatically flag which General Purpose Registers (GPRs) and Control and Status Registers (CSRs) are security-sensitive and capable of leaking information across privilege boundaries.

Applying Sailor's output to real-world codebases, the researchers evaluated the context switch implementations across three systems: the Keystone and Komodo open-source confidential computing frameworks, and a Linux kernel branch shipped for the StarFive VisionFive2 board. The results revealed multiple distinct security vulnerabilities stemming from mishandled ISA state. Specifically, the analysis found that Keystone failed to swap the senvcfg CSR and leaked Zicntr extension performance counters, introducing a timing side-channel. Komodo, relying on an outdated, self-written ISA specification, also failed to sanitize the senvcfg register and improperly handled Floating-Point (F-extension) state. Furthermore, both Komodo and the VisionFive2 Linux kernel failed to properly isolate or check Vector (V-extension) states. These manual oversights confirm that relying on human interpretation of dense ISA manuals routinely creates fatal state-leakage primitives, allowing unprivileged adversaries to compromise the computational integrity of secure enclaves[ 1, 2].

Microarchitectural FPU Register Leakage (Stecklina & Prescher / CVE-2018-3665): Beyond explicit architectural state, the microarchitectural environment presents an even wider attack surface. Stecklina and Prescher's LazyFP research demonstrated how performance-optimizing "lazy" context switching algorithms used by major operating systems inadvertently left Floating Point (FPU) and SIMD registers in place across privilege boundaries[ 3]. The paper mentions that although floating point registers may seem benign to leak, it was shown that crucial AES-impacting operations were done involving the SSE registers rendering them valid for exploitation. The authors proved that transient execution side-channels—similar to Meltdown—allow malicious processes to speculatively access the disabled FPU state of a completely separate process or VM and leak it before the processor's fault handler fully halts execution[ 3]. This specific vulnerability class is formally tracked as CVE-2018-3665, highlighting the critical danger of speculative execution bridging cache side-channels to extract SIMD register data. A summary of their evaluation shows that it takes more than 300,000 cycles, or 138 µs, to leak a complete AVX register. This firmly establishes that privileged boundaries must perform eager, immediate state clearing rather than relying on deferred exception-based isolation[ 3].

Hardware-Level TrustZone Leakage (Arm Security Advisory / CVE-2021-35465): Similar to compiler-level mishandling, hardware interrupt edge cases present a severe risk for floating-point state leakage. CVE-2021-35465 impacts Armv8-M architectures (e.g., Cortex-M33, M55) where an abandoned VLLDM instruction—interrupted mid-execution—leaves partially restored Secure floating-point data exposed. Because the context is not correctly flagged as active, a subsequent Non-secure interrupt handler can read or modify these registers, directly breaching the Secure enclave's isolation. This necessitates explicit software workarounds within the compiler toolchain to safely manage the interrupt window.

Compiler-Induced TrustZone Leakage (Arm Security Advisory / CVE-2024-7883): The interaction between compiler-generated code and hardware security extensions introduces another layer of risk. Recent advisories from Arm regarding CVE-2024-7883 reveal that LLVM-based compilers generating code for Cortex-M Security Extensions (CMSE) can inadvertently leak Secure stack contents to the Non-secure state[ 10]. Because the compiler mishandles the insertion of VLSTM and VLLDM instructions around floating-point returns, up to 64 bytes of confidential Secure stack data are exposed in registers S16–S31. This vulnerability demonstrates that even when hardware features like Armv8-M TrustZone are correctly implemented, compiler-level state management can compromise the isolation if it fails to correctly track floating-point initialization contexts.

Automated Vulnerability Discovery in Closed-Source CPUs (Thomas / RISCover): Bridging the gap between the specification and final silicon, Thomas (2025) introduces RISCover, demonstrating the critical need for automated pre/post-silicon validation. The RISCover tool hosts different CPU models and fuzzes them by generating a set of instructions to discover differential behavior. Evaluation consisted of running the tool across 12 physical RISC-V boards spanning CPUs from three vendors—SiFive, T-Head, and SpacemiT. Operating systems ranged from Ubuntu and Debian to NixOS and Armbian, with kernels spanning v5.4 through v6.6. Across this evaluation, RISCover identified distinct architectural security vulnerabilities one of which dubbed GhostWrite received formal CVE designation: CVE-2024-44067. These results concretely demonstrate that closed-source, vendor-specific CPU implementations routinely violate the privilege isolation guarantees prescribed by the RISC-V specification, and that automated black-box testing at the ISA boundary is both tractable and necessary for post-silicon security assurance.

Grounded in the academic insights and vulnerability patterns established by these studies, the following section translates theory into practice by providing concrete, assembly-level implementation guidelines for secure handoffs.

5. Implementation Guidance & Snippets

The core tenet of secure transition is Zeroization, Microarchitectural Sterilization, and Lock-Down. Below is the kernel-agnostic inline assembly implementation for RISC-V M-mode to S-mode transition, featuring absolute register zeroization, cache synchronization, and right-anchored interactive metadata tooltips for every instruction and register token.

5.2 RISC-V Kernel-Agnostic Absolute Zeroization Routine

Hover over any instruction mnemonic or register token below to inspect its instruction summary, architectural operand behavior, ABI naming conventions, and standard kernel usage context.

/* 
 * KERNEL-AGNOSTIC ABSOLUTE ZEROIZATION & TRANSITION ROUTINE
 * Written with volatile inline assembly, complete clobber specifications,
 * explicit instruction caching barriers, and zero trust register scrubbing.
 */

lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. rara (x1) - Return AddressUsage: Stores the return address for function calls.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard subroutine linkage across RISC-V calling conventions., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t0t0 (x5) - Temporary Register 0Usage: General-purpose scratch register for intermediate values.
ABI Role: Volatile caller-saved register.
Kernel ABI: Frequently used for short-lived scratch calculations within exception handlers., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t1t1 (x6) - Temporary Register 1Usage: Secondary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Used in trampolines and low-level context switches., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t2t2 (x7) - Temporary Register 2Usage: Tertiary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Scratch storage during trap vector entry code., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s0s0 / fp (x8) - Saved Register / Frame PointerUsage: Preserved across function calls; doubles as stack frame pointer.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Maintains stack frames across nested kernel routines., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s1s1 (x9) - Saved Register 1Usage: Preserved variable storage across calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved state across context saves., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a0a0 (x10) - Function Argument / Return Value 0Usage: Holds primary parameter inputs and return values.
ABI Role: Volatile caller-saved register.
Kernel ABI: In standard boot protocols, receives the hartid; zeroed here for kernel-agnostic security., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a1a1 (x11) - Function Argument / Return Value 1Usage: Holds secondary parameter inputs and return values.
ABI Role: Volatile caller-saved register.
Kernel ABI: Traditionally passes the Device Tree Blob (DTB) physical address., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a2a2 (x12) - Function Argument 2Usage: Third argument register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General subroutine parameter passing., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a3a3 (x13) - Function Argument 3Usage: Fourth argument register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General subroutine parameter passing., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a4a4 (x14) - Function Argument 4Usage: Fifth argument register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General subroutine parameter passing., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a5a5 (x15) - Function Argument 5Usage: Sixth argument register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General subroutine parameter passing., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a6a6 (x16) - Function Argument 6Usage: Seventh argument register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General subroutine parameter passing., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. a7a7 (x17) - Function Argument 7 / System Call IDUsage: Eighth argument register; conventionally used to pass syscall numbers.
ABI Role: Volatile caller-saved register.
Kernel ABI: Identifies the target system call identifier during ecall exceptions., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s2s2 (x18) - Saved Register 2Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s3s3 (x19) - Saved Register 3Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s4s4 (x20) - Saved Register 4Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s5s5 (x21) - Saved Register 5Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s6s6 (x22) - Saved Register 6Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s7s7 (x23) - Saved Register 7Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s8s8 (x24) - Saved Register 8Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s9s9 (x25) - Saved Register 9Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s10s10 (x26) - Saved Register 10Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. s11s11 (x27) - Saved Register 11Usage: Long-term variable preservation.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Preserved across kernel thread execution., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t3t3 (x28) - Temporary Register 3Usage: Additional temporary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Used for extended scratch space during register saves., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t4t4 (x29) - Temporary Register 4Usage: Additional temporary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Extended scratch register space., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t5t5 (x30) - Temporary Register 5Usage: Additional temporary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Extended scratch register space., 0;
lili - Load ImmediateAction: Loads a 32-bit immediate constant value into the destination register.
Operands: Destination Register, Immediate Value.
Kernel ABI: Pseudo-instruction mapped to addi or lui+addi sequences. t6t6 (x31) - Temporary Register 6Usage: High temporary scratch register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Frequently utilized in exception handlers as a secondary pointer scratchpad., 0;
fence.ifence.i - Instruction Cache FenceAction: Synchronizes instruction and data streams; ensures previous writes are visible as instructions.
Operands: None.
Kernel ABI: Mandatory instruction barrier following code modification or prior to privilege handoff.;             /* Instruction cache synchronization barrier */
mretmret - Machine ReturnUsage: Returns from a machine-mode exception handler.
Action: Restores privilege level from MPP, re-enables interrupts, and jumps to instruction address in mepc.
Kernel ABI: Core instruction utilized by M-mode bootloaders (e.g., OpenSBI) to yield control down to S-mode OS kernels.;

9.1 ARM Transition (AArch64 EL3 to EL1)

// DANGER: INSECURE IMPLEMENTATION
msrmsr - Move to System RegisterAction: Moves data from a general-purpose register into a specified system control register.
Operands: System Register, Source GPR.
Kernel ABI: System-level instruction used to configure privileged execution state (e.g., ELR_EL3). elr_el3elr_el3 - Exception Link Register (EL3)Usage: Holds the return address when exiting EL3 via ERET.
ABI Role: EL3 System Control Register.
Kernel ABI: Specifies the destination address in the lower exception level upon return., x20x20 - General Purpose Register 20Usage: Callee-saved general-purpose register.
ABI Role: Non-volatile preserved register.
Kernel ABI: Maintained across nested subroutine calls.
ereteret - Exception ReturnAction: Performs an exception return, restoring processor state from saved registers and jumping to ELR.
Operands: None.
Kernel ABI: Core instruction utilized by EL3 firmware or OS kernels to drop exception levels.;

Secure Pattern: State Scrubbing & Explicit Configuration

A secure transition actively zeros out all CPU state, flushes caches, and invalidates branch predictors. Every single register must be explicitly cleared to prevent residual leakage.

// SECURE EXAMPLE: Scrubbing registers and microarchitectural state

// 1. Explicitly set target execution state
mrsmrs - Move from System RegisterAction: Reads a system control register into a general-purpose register.
Operands: Destination GPR, System Register.
Kernel ABI: Used to inspect system flags, control bits, and configuration registers. x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., scr_el3scr_el3 - Secure Configuration Register (EL3)Usage: Defines secure state execution parameters at EL3.
ABI Role: EL3 System Register.
Kernel ABI: Controls security world routing (NS bit) and architectural execution states (RW bit).
orrorr - Bitwise ORAction: Performs a bitwise OR operation between two operands and stores the result.
Operands: Destination GPR, Source GPR, Bitmask.
Kernel ABI: Used to set specific configuration flags or control bits. x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., #(1 << 0)  // NS bit
orrorr - Bitwise ORAction: Performs a bitwise OR operation between two operands and stores the result.
Operands: Destination GPR, Source GPR, Bitmask.
Kernel ABI: Used to set specific configuration flags or control bits. x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., #(1 << 10) // RW bit
msrmsr - Move to System RegisterAction: Moves data from a general-purpose register into a specified system control register.
Operands: System Register, Source GPR.
Kernel ABI: System-level instruction used to configure privileged execution state. scr_el3scr_el3 - Secure Configuration Register (EL3)Usage: Defines secure state execution parameters at EL3.
ABI Role: EL3 System Register.
Kernel ABI: Controls security world routing (NS bit) and architectural execution states (RW bit)., x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register.

// 2. Set the return address to the verified kernel
msrmsr - Move to System RegisterAction: Moves data from a general-purpose register into a specified system control register.
Operands: System Register, Source GPR.
Kernel ABI: System-level instruction used to configure privileged execution state. elr_el3elr_el3 - Exception Link Register (EL3)Usage: Holds the return address when exiting EL3 via ERET.
ABI Role: EL3 System Control Register.
Kernel ABI: Specifies the destination address in the lower exception level upon return., x20x20 - General Purpose Register 20Usage: Callee-saved general-purpose register.
ABI Role: Non-volatile preserved register.
Kernel ABI: Maintained across nested subroutine calls.

// 3. Zeroize ALL General Purpose Registers to prevent data leakage
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x0x0 (r0) - Argument / Return Register 0Usage: Primary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Standard procedure call scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x1x1 (r1) - Argument / Return Register 1Usage: Secondary parameter and return value register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x2x2 (r2) - Argument Register 2Usage: Tertiary parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x3x3 (r3) - Argument Register 3Usage: Quaternary parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x4x4 (r4) - Argument Register 4Usage: Parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x5x5 (r5) - Argument Register 5Usage: Parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x6x6 (r6) - Argument Register 6Usage: Parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x7x7 (r7) - Argument Register 7Usage: Parameter passing register.
ABI Role: Volatile caller-saved register.
Kernel ABI: Procedure call argument passing., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x8x8 (r8) - Indirect Result RegisterUsage: Indirect return value address pointer.
ABI Role: Volatile caller-saved register.
Kernel ABI: Used for large structure returns., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x9x9 (r9) - Scratch Register 0Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x10x10 (r10) - Scratch Register 1Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x11x11 (r11) - Scratch Register 2Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x12x12 (r12) - Scratch Register 3Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x13x13 (r13) - Scratch Register 4Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x14x14 (r14) - Scratch Register 5Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x15x15 (r15) - Scratch Register 6Usage: Temporary working register.
ABI Role: Volatile caller-saved register.
Kernel ABI: General-purpose scratch register., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x16x16 (ip0) - Intra-Procedure-call Scratch Register 0Usage: Scratch register used by linker veneers.
ABI Role: Volatile caller-saved register.
Kernel ABI: Intra-procedure call scratch., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x17x17 (ip1) - Intra-Procedure-call Scratch Register 1Usage: Scratch register used by linker veneers.
ABI Role: Volatile caller-saved register.
Kernel ABI: Intra-procedure call scratch., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x18x18 (pr) - Platform Register / ReservedUsage: Platform-specific use or reserved as a permanent scratch/structure pointer.
ABI Role: Platform dependent.
Kernel ABI: Often reserved for TLS or shadow call stacks., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x19x19 - Callee-Saved Register 0Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x20x20 - Callee-Saved Register 1Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x21x21 - Callee-Saved Register 2Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x22x22 - Callee-Saved Register 3Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x23x23 - Callee-Saved Register 4Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x24x24 - Callee-Saved Register 5Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x25x25 - Callee-Saved Register 6Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x26x26 - Callee-Saved Register 7Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x27x27 - Callee-Saved Register 8Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x28x28 - Callee-Saved Register 9Usage: Preserved across function calls.
ABI Role: Non-volatile callee-saved register.
Kernel ABI: Function-scoped persistent data., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x29x29 (fp) - Frame PointerUsage: Points to the base of the current stack frame.
ABI Role: Dedicated frame pointer.
Kernel ABI: Used for stack unwinding and debugging., #0
movmov - Move Register / ImmediateAction: Copies data from a source register or immediate value into a destination register.
Operands: Destination GPR, Source Value.
Kernel ABI: Core data movement instruction across all procedure frames. x30x30 (lr) - Link RegisterUsage: Stores the subroutine return address in ARM64 ABI.
ABI Role: Dedicated link register.
Kernel ABI: Automatically populated during branch-with-link (bl) operations., #0

// 4. Microarchitectural Sterilization
icic - Instruction Cache MaintenanceAction: Manages instruction cache invalidation and maintenance operations.
Operands: Operation Modifier (e.g., iallu).
Kernel ABI: Used during self-modifying code execution or secure context switches to clear instruction caches. ialluiallu - Invalidate All to PoUUsage: Invalidates all instruction caches to the Point of Unification.
ABI Role: Cache maintenance operand.
Kernel ABI: Clears stale instruction cache entries across processors.           // Invalidate all instruction caches to PoU
tlbitlbi - Translation Lookaside Buffer InvalidateAction: Invalidates entries in the Translation Lookaside Buffer (TLB).
Operands: Target Domain (e.g., alle3).
Kernel ABI: Crucial for memory management unit re-mapping and domain switches. alle3alle3 - Invalidate TLB for EL3Usage: Flushes all TLB entries associated with Exception Level 3.
ABI Role: TLBI scope modifier.
Kernel ABI: Prevents speculative use of stale high-privilege virtual translations.         // Invalidate all TLB entries for EL3
dsbdsb - Data Synchronization BarrierAction: Forces complete execution of all prior memory access instructions before proceeding.
Operands: Domain Specifier (e.g., sy).
Kernel ABI: Ensures memory ordering constraints are fully satisfied. sysy - Full System DomainUsage: Applies synchronization barrier across the entire system shareability domain.
ABI Role: Barrier scope operand.
Kernel ABI: Guarantees system-wide memory transaction ordering.             // Data synchronization barrier
isbisb - Instruction Synchronization BarrierAction: Flushes the processor pipeline, ensuring all subsequent instructions are fetched after this barrier.
Operands: None.
Kernel ABI: Flushes context-changing side effects.                // Instruction synchronization barrier (flushes pipeline)

// 5. Execute safe transition
ereteret - Exception ReturnAction: Performs an exception return, restoring processor state from saved registers and jumping to ELR.
Operands: None.
Kernel ABI: Core instruction utilized by EL3 firmware or OS kernels to drop exception levels.;

9.3 x86_64 Transition (SMM to Ring 0)

; DANGER: INSECURE IMPLEMENTATION
; ... perform sensitive SMRAM operations ...
rsmrsm - Return from System Management ModeAction: Restores processor state from the SMRAM Save State Area and resumes interrupted OS execution.
Operands: None.
Kernel ABI: Exclusive SMM exit instruction executed by firmware handlers.            ; Exits SMM, but leaves all GPRs fully populated with firmware data!

Secure Pattern: SMRAM Lock and State Save Area Sanitization

When returning from SMM via RSM, the CPU restores state from the SMRAM Save State Area. A secure implementation explicitly flushes caches to prevent Prime+Probe leakage and exhaustively zeroizes all working registers.

; SECURE EXAMPLE: SMM Return (Explicit Zeroization)

; 1. Ensure all cores are synced before returning to prevent TOCTOU
; (Requires checking a multi-processor sync flag)

; 2. Scrub ALL general purpose registers inside the SMM handler
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. raxrax - Accumulator RegisterUsage: Primary accumulator for arithmetic operands and function return values.
ABI Role: Volatile general-purpose register.
Kernel ABI: Holds system call numbers (in x86_64 syscall ABI) and return values., raxrax - Accumulator RegisterUsage: Primary accumulator for arithmetic operands and function return values.
ABI Role: Volatile general-purpose register.
Kernel ABI: Holds system call numbers (in x86_64 syscall ABI) and return values.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rbxrbx - Base RegisterUsage: Traditionally used for base addressing; non-volatile in x86_64 ABI.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames., rbxrbx - Base RegisterUsage: Traditionally used for base addressing; non-volatile in x86_64 ABI.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rcxrcx - Counter RegisterUsage: Used for loop counting and shift/rotate operations; fourth argument in Windows ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Overwritten during syscall instructions to store return instruction pointers (RIP)., rcxrcx - Counter RegisterUsage: Used for loop counting and shift/rotate operations; fourth argument in Windows ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Overwritten during syscall instructions to store return instruction pointers (RIP).
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rdxrdx - Data RegisterUsage: Secondary accumulator for I/O port addressing and multiplication/division.
ABI Role: Volatile general-purpose register.
Kernel ABI: Third argument register in System V AMD64 ABI., rdxrdx - Data RegisterUsage: Secondary accumulator for I/O port addressing and multiplication/division.
ABI Role: Volatile general-purpose register.
Kernel ABI: Third argument register in System V AMD64 ABI.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rsirsi - Source Index RegisterUsage: Pointer for string source operands; second argument in System V ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Standard parameter passing register for function calls., rsirsi - Source Index RegisterUsage: Pointer for string source operands; second argument in System V ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Standard parameter passing register for function calls.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rdirdi - Destination Index RegisterUsage: Pointer for string destination operands; first argument in System V ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Primary argument register across Unix-like kernel routines., rdirdi - Destination Index RegisterUsage: Pointer for string destination operands; first argument in System V ABI.
ABI Role: Volatile general-purpose register.
Kernel ABI: Primary argument register across Unix-like kernel routines.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. rbprbp - Base Pointer RegisterUsage: Stack frame base pointer.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Maintained across stack frames for debugging and backtrace generation., rbprbp - Base Pointer RegisterUsage: Stack frame base pointer.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Maintained across stack frames for debugging and backtrace generation.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r8r8 - General Purpose Register 8Usage: Extended 64-bit general-purpose register; fifth function argument.
ABI Role: Volatile general-purpose register.
Kernel ABI: Argument passing in 64-bit calling conventions., r8r8 - General Purpose Register 8Usage: Extended 64-bit general-purpose register; fifth function argument.
ABI Role: Volatile general-purpose register.
Kernel ABI: Argument passing in 64-bit calling conventions.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r9r9 - General Purpose Register 9Usage: Extended 64-bit general-purpose register; sixth function argument.
ABI Role: Volatile general-purpose register.
Kernel ABI: Argument passing in 64-bit calling conventions., r9r9 - General Purpose Register 9Usage: Extended 64-bit general-purpose register; sixth function argument.
ABI Role: Volatile general-purpose register.
Kernel ABI: Argument passing in 64-bit calling conventions.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r10r10 - General Purpose Register 10Usage: Extended 64-bit general-purpose register.
ABI Role: Volatile general-purpose register.
Kernel ABI: Scratch register in x86_64 calling conventions., r10r10 - General Purpose Register 10Usage: Extended 64-bit general-purpose register.
ABI Role: Volatile general-purpose register.
Kernel ABI: Scratch register in x86_64 calling conventions.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r11r11 - General Purpose Register 11Usage: Extended 64-bit general-purpose register.
ABI Role: Volatile general-purpose register.
Kernel ABI: Overwritten during syscall instructions to store processor flags (RFLAGS)., r11r11 - General Purpose Register 11Usage: Extended 64-bit general-purpose register.
ABI Role: Volatile general-purpose register.
Kernel ABI: Overwritten during syscall instructions to store processor flags (RFLAGS).
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r12r12 - General Purpose Register 12Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames., r12r12 - General Purpose Register 12Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r13r13 - General Purpose Register 13Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames., r13r13 - General Purpose Register 13Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r14r14 - General Purpose Register 14Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames., r14r14 - General Purpose Register 14Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames.
xorxor - Bitwise Exclusive ORAction: Performs logical exclusive OR; clearing a register with itself is an optimized zeroization idiom.
Operands: Destination GPR, Source GPR.
Kernel ABI: Universal idiom used across architectures for fast register zeroing. r15r15 - General Purpose Register 15Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames., r15r15 - General Purpose Register 15Usage: Extended 64-bit general-purpose register.
ABI Role: Callee-saved general-purpose register.
Kernel ABI: Preserved across function call frames.

; 3. Flush Caches to prevent Prime+Probe leakage of SMM data
wbinvdwbinvd - Write Back and Invalidate CacheAction: Writes back all modified cache lines to main memory and invalidates all cache contents.
Operands: None.
Kernel ABI: Privileged instruction used in firmware/SMM routines to eliminate cache side-channels.         ; Write back and invalidate cache

; 4. Lock SMRAM (if not already locked by hardware controller)

; 5. Return from System Management Mode safely
rsmrsm - Return from System Management ModeAction: Restores processor state from the SMRAM Save State Area and resumes interrupted OS execution.
Operands: None.
Kernel ABI: Exclusive SMM exit instruction executed by firmware handlers.

Bridging our architectural review, empirical literature, and assembly patterns, the concluding section summerizes our primary recommendations for bulletproof firmware handoffs[10].

10. Conclusion

The architectural handover from an immutable secure bootloader to a rich operating system represents a critical phase shift in system security. Hardware architectures provide the mechanisms for isolation, but software must rigorously enforce the policy during context switches. Failing to clear registers, explicitly lock memory protection units, or flush the microarchitectural state prior to executing exception returns renders the preceding cryptographic signature checks functionally useless, granting an attacker persistent access to secure enclaves.

Even though specifications exist at the pre-silicon level (RTL, hardware design, etc.), implementation is still free to violate this via undocumented or unintended side effects. The compartmentalized nature of hardware manufacturing means that each stage of definition, compilation, and deployment brings with it an opportunity for influence and defense. For instance, leaving a privilege escalation flaw in a development mode might be safe in one environment but provide opportunities to third parties in another, leaving an organization no actual control over what reaches their users.

In order to manage these risks, hardware designers need to ensure that they have accurately threat modeled each stage of development, baking in pre-silicon, compile, and post-silicon risks. Ultimately, maintaining hardware-enforced isolation requires (i) active testing at every phase of the lifecycle, encompassing both pre-silicon validation and post-silicon verification; (ii) active research that stays continually aware of contemporary vulnerabilities and microarchitectural side-channels; and (iii) a continuous adaptation to new testing technology and automated evaluation methodologies.

11. References

1. Kalani, N. S., Bourgeat, T., Hunt, G. D. H., & Ozga, W. (2025). "Automatic ISA analysis for Secure Context Switching." arXiv preprint arXiv:2502.06609.
2. Kalani, N. S., Bourgeat, T., Hunt, G. D. H., & Ozga, W. (2025). "Save what must be saved: Secure context switching with Sailor." USENIX Security Symposium
3. Stecklina, J., & Prescher, T. (2018). "LazyFP: Leaking FPU Register State using Microarchitectural Side-Channels." arXiv preprint arXiv:1806.07480
4. Koruyeh, E. M., Shiravan, K. N., Khasawneh, K. N., Bingham, C., & Abu-Ghazaleh, N. (2018). "Spectre Returns! Speculation Attacks using the Return Stack Buffer." 12th USENIX Workshop on Offensive Technologies (WOOT 18)
5. Kuhne et al. (2025). "DORAMI: Privilege Separating Security Monitor on RISC-V TEEs." USENIX Security Symposium
6. Haj-Yahya, J., et al. (2019). "Lightweight Secure-Boot Architecture for RISC-V System-on-Chip." IEEE
7. Zhang, X., et al. (2016). "TruSpy: Cache Side-Channel Information Leakage from the Secure World on ARM Devices." IACR Cryptology ePrint Archive.
8. ARM Architecture Reference Manual (AArch64). Section: Exception handling and state transitions.
9. RISC-V Instruction Set Manual, Volume II: Privileged Architecture. Section: Physical Memory Protection (PMP).
10. CVE-2024-7883 Floating point register leakage https://support.arm.com/documentation/110370/latest
11. CVE-2024-7883 NVD - https://nvd.nist.gov/vuln/detail/CVE-2024-7883
12. Reid, A. (2016). "Trustworthy Specifications of ARM v8-A and v8-M System Level Architecture." In Proceedings of the 2016 Formal Methods in Computer-Aided Design (FMCAD), pp. 161-168.
13. Intel Corporation. (2026). Intel® 64 and IA-32 Architectures Software Developer's Manual.
14. Waterman, A., & Asanović, K. (2019). "The RISC-V Instruction Set Manual, Volume I: Unprivileged ISA." RISC-V Foundation.
15. Patterson, D. A., & Hennessy, J. L. (2017). Computer Organization and Design RISC-V Edition: The Hardware/Software Interface. Morgan Kaufmann.
16. Armv8-M VLLDM instruction security vulnerability (CVE-2021-35465). Arm Developer Support. https://support.arm.com/documentation/110365/latest
17. Thomas, F. (2025). "RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs." https://fabianthomas.de/pdfs/thomas2025riscover.pdf
18. even629. (2025). "ARM Memory Management." Covers AArch64 VMSA paging mechanisms, multi-level page tables (L0–L3), MMU hardware, TTBR registers, TLB role, and VA→IPA→PA translation in virtualised environments. Available at: https://even629.com/en/posts/2510241/
19. Sharma, B. (2020). "Understanding 52-bit virtual address support in the Arm64 kernel." Opensource.com. Discusses the extension from 48-bit to 52-bit virtual addressing on ARMv8.2-A, new page table levels, and ARM kernel memory layout. Available at: https://opensource.com/article/20/12/52-bit-arm64-kernel
20. Bepary, M. K., Zhang, T., Farahmandi, F., & Tehranipoor, M. (2024). "PreSCAN: A Comprehensive Review of Pre-Silicon Physical Side-Channel Vulnerability Assessment Methodologies." Chips, 3(4), 311–333. https://www.mdpi.com/2674-0729/3/4/16