Exception-Driven Security: A Risk-Aware Permission Adjustment for High-Availability Embedded Systems

Abstract

Real-time operating systems (RTOSs) are widely used in embedded systems to ensure deterministic task execution, predictable responses, and concurrent operations, which are crucial for time-sensitive applications. However, the growing complexity of embedded systems, increased network connectivity, and dynamic software updates significantly expand the attack surface, exposing RTOSs to a variety of security threats, including memory corruption, privilege escalation, and side-channel attacks. Traditional security mechanisms often impose additional overhead that can compromise real-time guarantees. In this work, we present a Risk-aware Permission Adjustment (RPA) framework, implemented on CHERIoT RTOS, which is a CHERI-based operating system. RPA aims to detect anomalous behavior in real time, quantify security risks, and dynamically adjust permissions to mitigate potential threats. RPA maintains system continuity, enforces fine-grained access control, and progressively contains the impact of violations without interrupting critical operations. The framework was evaluated through targeted fault injection experiments, including 20 real-world CVEs and 15 abstract vulnerability classes, demonstrating its ability to mitigate both known and generalized attacks. Performance measurements indicate minimal runtime overhead while significantly reducing system downtime compared to conventional CHERIoT and FreeRTOS implementations.

1. Introduction

The rapid proliferation of Cyber–Physical Systems (CPSs), Industrial Control Systems (ICSs), the Internet of Things (IoT), smart transportation, medical devices, and other interconnected technologies has made high-availability embedded systems (ESs) an integral part of modern life. These systems often consolidate multiple applications and components within a single, non-isolated address space running on lightweight real-time operating systems (RTOSs). RTOSs are employed to ensure deterministic performance, predictable responses, and concurrent task execution, which are essential for time-critical applications [1]. However, the consolidation of system components increases the attack surface, particularly as network connectivity and dynamic software updates become more common [2].

Security analyses reveal that vulnerability-based attacks, such as buffer overflows, are frequent in ES and can result in unauthorized access, data leakage, or system crashes [3]. RTOSs, designed to operate under strict memory and processing constraints, often lack default protections such as memory isolation and access control, making them susceptible to memory corruption, privilege escalation, and side-channel attacks [4]. For example, the Urgent/11 vulnerabilities publicized in 2019 exposed hundreds of millions of VxWorks-powered medical devices and industrial controllers to remote code execution and denial of service, threatening patient monitors and critical infrastructure [5]. Similarly, the NUCLEUS:13 TCP/IP flaws in Siemens Nucleus RTOS jeopardized anesthesia machines and patient monitors in 2021, with critical risks of system compromise and harm to patient care [6]. Integrating traditional security measures, while necessary, can introduce additional complexity that may impact timing accuracy and real-time guarantees.

A recent analysis of the National Vulnerability Database (NVD) highlights a significant and growing number of vulnerabilities reported in embedded and real-time operating systems. As of late 2024, there were over 18,000 vulnerabilities still awaiting full analysis due to increasing submission rates, with year-over-year growth in CVE reports reaching approximately 30% to 33% [7,8]. Notably, numerous critical vulnerabilities have been disclosed in popular RTOS platforms such as FreeRTOS and Apache NuttX, including memory corruption and privilege escalation bugs that compromise foundational system security [9,10]. Industry trend analyses confirm that embedded systems are high-risk targets frequently affected by exploits that leverage these vulnerabilities [11]. In 2024 alone, more than 40,000 vulnerabilities were cataloged, underscoring the urgency of enhancing RTOS security without compromising real-time performance [12].

As ESs continue to grow in complexity, ensuring reliability and security without compromising performance becomes increasingly critical. Standardized references, such as the Common Weakness Enumeration (CWE) [13] and Common Vulnerabilities and Exposures (CVE) [14], help identify and track known weaknesses. For instance, FreeRTOS [15] recently addressed CVE-2021-43997, a kernel vulnerability threatening the confidentiality and availability of sensitive data. Table 1 summarizes publicly reported FreeRTOS vulnerabilities from September 2018 onward, highlighting security issues ranging from medium to critical severity levels.

Table 1. List of vulnerabilities and CVE identifiers affecting FreeRTOS [16].

CVE	FreeRTOS Library	Severity	Version
CVE-2018-16522	Secure Sockets	High	Amazon FreeRTOS v1.3.2
CVE-2018-16523	FreeRTOS + TCP	High	Amazon FreeRTOS v1.3.2
CVE-2018-16524	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16525	FreeRTOS + TCP	High	Amazon FreeRTOS v1.3.2
CVE-2018-16526	FreeRTOS + TCP	High	Amazon FreeRTOS v1.3.2
CVE-2018-16527	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16528	Secure Sockets	High	Amazon FreeRTOS v1.3.2
CVE-2018-16598	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16599	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16600	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16601	FreeRTOS + TCP	High	Amazon FreeRTOS v1.3.2
CVE-2018-16602	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2018-16603	FreeRTOS + TCP	Medium	Amazon FreeRTOS v1.3.2
CVE-2019-13120	MQTT	High	Amazon FreeRTOS v1.4.9
CVE-2021-31571	FreeRTOS Kernel	Critical	FreeRTOS Kernel v10.4.3
CVE-2021-31572	FreeRTOS Kernel	Critical	FreeRTOS Kernel v10.4.3
CVE-2021-32020	FreeRTOS Kernel	Critical	FreeRTOS Kernel v10.4.3
CVE-2021-43997	FreeRTOS Kernel	High	FreeRTOS Kernel v10.4.6
			and v10.4.3-LTS- Patch-2

To mitigate these risks, researchers have explored both software- and hardware-based approaches to reinforce ES security [17,18,19,20,21,22,23,24,25]. Software approaches often involve unavoidable overhead when trapping to the kernel, and message passing can result in the need for multiple data copying operations. Although current hardware assistance, such as privilege rings [26], Memory Management Unit (MMU), and Mondrian Memory Protection (MMP) [27], try to keep systems tamper-proof against vulnerabilities in RTOSs, they are not efficient enough to meet all security needs. For example, MMUs translate virtual addresses to protect memory and manage the processor cache, and MMP has a map linking addresses to permissions on word-level protection saved in kernel memory.

However, both technologies heavily depend on virtual address handling, which may introduce some variable overhead and potentially affect real-time guarantees on ES. TrustZone [28], another hardware approach developed by ARM to support Cortex-M processors, provides robust levels of protection for IoT devices. This isolates critical security firmware, assets, and private information from the application, reducing the potential for attack. However, it is not entirely immune to vulnerabilities and lacks scalability and fine-grained security. Its primary disadvantage is that if a vulnerability is exploited in the secure world, it could potentially compromise the entire system, as the secure world has full access.

The purpose of the work presented in this paper is to focus on mitigating RTOS vulnerabilities, with a primary emphasis on using FreeRTOS for examples and discussions (see Section 4).

2. Problem State and Motivation

This section outlines the prerequisites for developing an enhanced system call (syscall) model within FreeRTOS, focusing on improving security without compromising real-time performance. Our design objectives address three key requirements:

2.1. Tamper-Proof System Call Code

While system calls (for short, syscalls) in RTOSs provide a means for user tasks to interact with the OS kernel, they have certain limitations. These include a lack of a standardized interface, a limited number of syscalls, low flexibility, and a lack of configurability. For example, in FreeRTOS, syscalls allow unprivileged tasks to temporarily raise their privilege level, access kernel services, and then reset to their original privilege level before returning to the calling task [29]. Unfortunately, this makes them vulnerable to exploitation, as system calls that accept function pointers as parameters can be leveraged to achieve arbitrary code execution. Moreover, FreeRTOS lacks an access control (AC) model, such as a conventional access control list (ACL) or the file systems found in UNIX-based operating systems. As a result, there are no safeguards to prevent attackers from accessing all system resources and the entire memory of such systems.

Existing syscall hardening approaches commonly rely on access control lists, memory protection units, and static or dynamic program analyses aimed at mitigating such vulnerabilities. Our approach advances syscall security by integrating hardware-enforced capability-based permission adjustment, enabling fine-grained, dynamic privilege management that adapts at runtime to observed risk. This capability-based mechanism surpasses static or coarse-grained controls by dynamically monitoring and restricting syscall operations at the hardware level, effectively preventing exploitation vectors such as arbitrary code execution through function pointer abuse. Achieving this, however, requires ensuring that the syscall code itself maintains strict integrity: it must be resistant to memory corruption, avoid re-entrance issues during interrupts, enforce secure parameter management to prevent use-after-free vulnerabilities, and eliminate race conditions that could compromise intended functionality.

2.2. Compliance for Privilege Separation

Privilege management is a core element of secure syscall design, involving precise control over which resources, actions, and conditions are accessible to specific entities. According to OWASP’s definition of Broken Access Control [30], failure to enforce proper restrictions can allow users to exceed their authorized permissions. One manifestation of this issue is the confused deputy problem [31], where a high-privilege process is tricked into performing unauthorized actions on behalf of a less-privileged entity.

While ACLs are common in CPS devices, they typically fail to enforce privilege separation. ACLs define who can access a resource but do not inherently restrict how much authority a task retains for regular operations. Misconfigurations further exacerbate risks, potentially granting unauthorized access to sensitive assets. To address these limitations, our goal is to design a syscall mechanism that enforces strict, role-based privilege separation, ensures functionalities remain within intended scope, and prevents escalation beyond predefined boundaries.

2.3. Real-Time Guarantees

In RTOSs, security mechanisms must not violate real-time constraints, as such violations can introduce delays and degrade system performance. For instance, cached memory translation and protection may compromise the low-latency and deterministic behavior of ES. Therefore, security architectures must be designed to satisfy the stringent timing requirements of ES without impacting performance.

3. Contribution

The significance of this research lies in introducing an adaptive security framework that strengthens RTOS security by leveraging CHERI’s runtime exception analysis and lifecycle management capabilities. The key contributions of this paper are as follows:

• Presents an in-depth examination of RTOS architectures and their features, with a focus on identifying and analyzing security vulnerabilities (particularly in syscall design) and the inherent challenges of building secure, tamper-resistant embedded systems.
• Proposes a dynamic security model that augments CHERI’s memory protection capabilities through adaptive policy enforcement. By monitoring CHERI-triggered exceptions, the framework detects anomalous behavior and dynamically adjusts permissions to contain security threats without disrupting essential system operations.
• Performs a detailed evaluation of the proposed framework’s impact on both security and system performance. Two case studies are presented to demonstrate its effectiveness in handling security violations while preserving the integrity, availability, and real-time properties of the operating system.

The remainder of this paper is organized as follows: Section 4 provides essential background information on the system call workflow in RTOS, which forms the foundation for our proposed model. Section 5 reviews relevant studies in this domain. Section 6 details our proposed model and outlines the design requirements. Section 7 presents the implementation and evaluation of the proposed model, including an analysis and comparison of the results. Finally, Section 8 concludes the paper and discusses potential directions for future research.

4. Background

This section presents the fundamental concepts underpinning the proposed work, using FreeRTOS as a representative example.

4.1. Real-Time Operating System

RTOSs play a critical role in managing embedded applications with stringent timing and reliability constraints, ensuring deterministic task execution and predictable system behavior. FreeRTOS [15], a widely adopted open-source RTOS introduced in 2003 by Richard Barry, is specifically designed to support such requirements through a lightweight yet modular architecture optimized for embedded platforms.

To protect critical resources and maintain system integrity, FreeRTOS implements a two-level privilege model that distinguishes between privileged and unprivileged operations. Privileged operations encompass core kernel functionalities such as task scheduling, synchronization, inter-task communication, and memory management, all of which have direct access to hardware resources. In contrast, unprivileged operations are associated with user applications and custom functionalities, which interact with the kernel exclusively through well-defined APIs. This separation enforces a strict boundary between user code and kernel operations, reducing the risk of accidental faults or malicious interference while preserving system stability.

4.2. FreeRTOS Services

FreeRTOS provides a range of kernel services which form the foundation for reliable and predictable system behavior. These services are outlined as follows.

4.2.1. Memory Management

While virtual memory and MMUs are standard in general-purpose computing, embedded systems have historically used them sparingly due to limited multiprogramming requirements. Modern embedded applications, however, often require controlled memory access among multiple tasks. To address this without MMU complexity, many microcontrollers implement Memory Protection Units (MPUs) [23], which define task-specific memory regions to prevent interference and mitigate memory-related errors. FreeRTOS supports MPUs on ARMv7-M and ARMv8-M cores, with MPU and Floating Point Unit (FPU) support configurable via FreeRTOSConfig.h.

Dynamic memory allocation is also supported, either from the FreeRTOS heap or provided by the application. Standard C functions (malloc(), free()) are usable, but FreeRTOS offers a portable layer optimized for embedded constraints. Five sample heap schemes (heap_1 to heap_5) provide different trade-offs, from simple allocation without task deletion (heap_1) to advanced strategies reducing fragmentation (heap_4) and spanning non-contiguous memory regions (heap_5) for flexible real-time memory management [32].

4.2.2. Task Management

Tasks are created with xTaskCreate() or xTaskCreateStatic(), with the former using heap memory automatically, and the latter requiring developer-provided memory. Task scheduling is priority-based: the highest-priority ready task enters the Running state. FreeRTOS tasks may also enter Blocked, Ready, or Suspended states depending on events or explicit API calls (vTaskSuspend(), vTaskResume()).

4.2.3. Inter-Task Communication

Queues serve as the primary mechanism for inter-task communication, supporting both static and dynamic memory allocation. Queues are created via xQueueCreate(), specifying capacity and item size, and data is exchanged using xQueueSend() and xQueueReceive() [33]. FreeRTOS emphasizes a minimal ROM footprint by using a single queue primitive for all communication.

4.2.4. Resource Management

To ensure safe access to shared resources, FreeRTOS provides mutexes and semaphores in both binary and counting formats [34,35,36,37]. Mutexes enforce mutual exclusion, optionally tracking the owning task, while counting semaphores act as event counters, blocking tasks when the value is zero. Binary semaphores, restricted to values of 0 and 1, typically protect single shared resources.

4.3. An Introduction to CHERI

The CHERI (Capability Hardware Enhanced RISC Instructions) protection model introduces architectural primitives that enable strong safety and security guarantees for C and C++ language pointers. Traditional pointers are typically implemented as architectural integers, which provide no built-in bounds or access protections. In contrast, CHERI introduces capabilities, a new data type that combines an address with metadata describing bounds, permissions, and provenance. These metadata fields allow the hardware to enforce memory safety directly, preventing common vulnerabilities such as buffer overflows, out-of-bounds execution, and unauthorized access to memory regions. Capabilities maintain monotonicity, ensuring that derived capabilities can only restrict, not expand, the access rights of the original capability. They also include a tag bit that indicates validity, along with a permissions mask to control access to data and code, enabling fine-grained enforcement of security policies. A CHERI capability contains several fields that define its properties and control access to memory. Figure 1 illustrates a typical capability layout. Each field plays a specific role:

Figure 1. A 128-bit memory representation of a capability.

• Tag bit (1 bit): Indicates whether a valid capability is present in a register or memory. If set, the capability is valid and can be dereferenced (subject to additional checks). If clear, the capability is invalid.
• Permissions mask (perms): Defines hardware-enforced access rights, with the first 12 bits. Permissions are limited by the current architectural ring and influenced by the tag.
• Flags (f): An architecture-specific field accessible via CGetFlags (read) and CSetFlags (write). No architecture-neutral flags are defined.
• Object type (otype, 4 bits for 64-bit: Specifies whether the capability is sealed and its type. Sealed capabilities are immutable and non-dereferenceable; they can be unsealed with CUnseal or through control transfer instructions CInvoke, CJALR).
• Bounds: Encodes the lower and upper limits of the memory region that the capability can reference. Bounds are compressed relative to the address and enforce spatial memory safety by preventing out-of-range accesses.

5. Related Work

There is a long history of research aimed at enhancing the security of embedded systems. This section reviews prior studies focused on improving RTOS security, particularly regarding system calls and privilege enforcement.

Software protection techniques form a foundational layer in embedded system security, aiming to prevent unauthorized use, exploitation, and reverse engineering. Key strategies include enforcing memory safety through tools and sanitizers [38,39,40,41,42], leveraging safe programming languages such as Ruby, Rust, and Swift [43,44,45,46], and applying formal verification methods that mathematically assure correctness and security properties [47,48]. Compiler-based approaches, including memory sanitizers and address sanitizers [49,50,51,52,53,54], complement these by detecting runtime violations and reducing vulnerabilities. Collectively, these techniques enhance software reliability and security while maintaining the performance demands of real-time embedded environments.

Hardware-assisted protection mechanisms complement software defenses by enforcing isolation and controlling access at the hardware level. MPUs [23] and Mutable Protection Domains (MPDs) [55] provide task-level memory isolation, preventing unauthorized access and mitigating side-channel attacks. For instance, COMPOSITE OS [56] employs MPUs to implement user-level components with hardware-enforced separation, enhancing system stability and security. Similarly, CompartOS [25] leverages CHERI capabilities to isolate execution environments within FreeRTOS, demonstrating how hardware-based mechanisms can improve memory protection and overall system resilience.

Access control remains a critical component in embedded system security, determining user permissions, authentication methods, and authorization levels to ensure that only authorized entities can access critical data or functionalities. For example, Harryson [57] proposes language-based permissions for embedded systems, implementing role-based access control (RBAC) on FreeRTOS using a Datalog query engine. This study demonstrates the efficiency of integrating access control into existing codebases while highlighting performance challenges associated with query evaluation. Similarly, Wang et al. [58] present a method for securing RTOS architectures in building automation. Their approach uses a formal language to define security policies governing inter-process communication, which are compiled into an Access Control Table (ACT) stored in the kernel. The microkernel references this table to verify process interactions and monitors characteristics such as worst-case execution time to ensure compliance, thereby improving system security and reliability.

Capability-based systems offer a flexible and fine-grained approach to access control, addressing limitations of traditional ACLs. Capabilities [59,60] are unforgeable tokens referencing resources and encapsulating permissions, enforcing the Principle of Least Privilege. They can be transferred, delegated, or invoked to dynamically manage access. Software implementations such as Hydra [61], seL4 [47], Fiasco [62], EROS [63], and Capsicum [64], as well as hardware-assisted systems like CHERI [65], demonstrate the versatility of capability-based mechanisms. Furthermore, frameworks such as CAPLets [66] and SEAL [67] extend these principles to IoT devices and shared-data computations, while language-based systems like Joe-E [68] and Caja [69] embed capability controls directly into programming languages, reducing vulnerabilities at the application level.

Formally verified kernels such as seL4 epitomize security assurance through mathematically proven correctness and rigorous enforcement of security policies [47]. Leveraging a capability-based design, seL4 guarantees properties like integrity, confidentiality, and fault isolation down to the binary level, providing strong assurance that kernel implementation matches its formal specification. While seL4 offers a minimal, formally verified trusted kernel foundation, this work enhances operational resilience with continuous risk scoring and progressive permission containment to maintain high system availability and continuity in the presence of security violations. This blend of formal assurance and adaptive risk-aware mitigation situates our approach uniquely within the landscape of cutting-edge embedded system security.

Recent work by Ferraro et al. [70] demonstrates the potential of CHERI for dynamic security in embedded network stacks. Their study on CheriBSD deployed on Arm Morello hardware highlights how capability-based compartmentalization can isolate components such as TCP/IP libraries and drivers, significantly reducing attack surfaces while preserving system performance in interconnected environments. Similarly, the CHERIoT platform [71] presents a co-designed RTOS with CHERI extensions offering dynamic spatial and temporal memory safety and lightweight compartmentalization. This greenfield system targets constrained embedded devices, supporting scalable security enforcement with efficient runtime overhead. Additionally, Amar et al. [72] provide a comprehensive study on memory safety enforcement in CHERI-based embedded devices, demonstrating dynamic security and formal verification techniques that further improve resilience against runtime attacks.

6. Design Overview

This section presents a capability-based architecture for RTOS that leverages CHERI to enhance system security, focusing on mitigating potential exploits and unauthorized access. The proposed framework integrates CHERI-based capabilities to provide fine-grained memory protection and access control while addressing critical performance and availability requirements. Embedded systems in high-availability, safety-critical environments demand continuous operation with near-zero downtime to ensure reliability and service continuity. The proposed RPA framework aligns with these industrial requirements by dynamically adjusting permissions and enabling fault mitigation without halting threads, thus preserving system availability and meeting zero-downtime operational goals. We first define the key design principles and requirements that guide the framework and then provide a detailed explanation of the model’s operation. The core innovation lies in CHERI-based dynamic permission adjustment, which detects security risks in real time and proactively adapts privileges to mitigate threats.

As mentioned earlier, RTOSs are meticulously designed to operate with limited memory and computing resources, resulting in default configurations that often lack essential security features such as memory protection and robust access control. CHERI-based RTOSs present a promising solution by using capabilities as the foundational security mechanism. Each capability encodes fine-grained bounds and permissions within unforgeable pointers, enforcing both memory safety and controlled access. Hardware-enforced CHERI exceptions provide synchronous checks, triggered whenever a capability violation occurs, such as accessing memory outside permitted bounds, misusing permissions, or referencing invalid capabilities.

When a capability exception is detected, CHERI halts the offending thread immediately, preventing further execution with unauthorized or corrupted capabilities and preserving system integrity. While this fail-stop approach is effective for security, it introduces challenges for high-availability systems that require continuous operation. To overcome this limitation, the proposed framework implements an adaptive, risk-aware mechanism that dynamically adjusts privileges based on detected risks, maintaining functionality without compromising security. A detailed quantitative trade-off analysis between false positives and availability, including thread continuation rates and system downtime, is provided in Section 7.2, demonstrating that the proposed approach delivers strong protection while substantially improving system availability.

However, the fail-stop approach, which halts offending threads immediately upon capability violations, can result in thread termination and service disruption. This is problematic for high-availability systems where continuous operation is critical. The RPA framework addresses this research gap by implementing adaptive, risk-aware privilege adjustments that maintain system continuity without forcing thread termination, thereby mitigating the fail-stop limitation inherent in conventional CHERI-based RTOS designs.

As illustrated in Listing 1, the code snippet defines the capability_t structure, representing a capability in CHERI. Each field in the structure captures essential metadata, including the capability’s bounds, current address, access permissions, object type, and validity status. Building on this representation, Listing 2 demonstrates a load operation using a CHERI capability. The load_from_capability function takes a capability_t pointer and an offset as arguments, performing several checks before executing the load operation.

Listing 1. Capability structure in the code.

Listing 2. Pseudo-code for a Load Instruction Using my_cap.

   First, a bounds check ensures that the requested offset lies within the capability’s length, preventing memory access outside the allocated region. Next, a permission check verifies that the PERM_LOAD flag is set in the capability’s permissions bitmask, enforcing the principle of least privilege. Additionally, a tag check validates the capability’s integrity by inspecting the tag field—a critical step in CHERI to prevent the use of corrupted or forged capabilities. If all checks pass, the function proceeds with memory access by dereferencing the address computed from the capability’s base plus the given offset.

6.1. Risk Detection Mechanism

This section presents an algorithm called Risk-aware Permission Adjustment (RPA) that allows the kernel to proactively monitor capability actions and detect anomalous activity that could indicate potential security breaches. Unlike traditional adaptive access control systems such as RBAC with static or real-time policy updates, the RPA framework uniquely leverages hardware-enforced CHERI exceptions as immediate and fine-grained indicators of security violations. Our design combines thread-level and compartment-level sliding-window monitoring to capture both localized and system-wide risk patterns. The dynamic risk score calculation incorporates exception frequency, severity, and timing—providing context-aware privilege adjustments. This integration facilitates rapid, adaptive permission modifications that maintain operational continuity while enforcing security, surpassing the reactive nature of existing models. First, we define key terms used in the risk detection algorithm:

• Risk: Any unusual behavior that deviates from expected operations may indicate a potential security breach. CHERI utilizes hardware-enforced capabilities to provide fine-grained memory protection and prevent unauthorized access. These capabilities trigger exceptions when a thread, compartment, or other task entity attempts an action that violates defined permissions, such as accessing memory outside bounds or performing operations without the required privileges. We leverage these exceptions to define a quantitative variable called the Risk Score, calculated based on exception features discussed later in this chapter. When an exception occurs in CHERI, specific registers capture detailed information, including the type and cause of the exception and the address of the faulting memory reference. These registers include the following:

  –

  mcause: Machine Cause register (32 bits); contains the cause of the standard RISC-V exception or interrupt.

  –

  mepc: Machine Exception Program Counter register (32 bits); stores the address of the instruction that caused the exception.

  –

  mtval: Machine Trap Value register (32 bits); holds exception-specific information to assist in handling capability-related exceptions, as illustrated in Figure 2.

  The proposed model focuses on using the mtval register to extract relevant exception information. As shown in Listing 3, register decoding interprets the fields as follows:

  –

  capcause = mtval & 0x1f: Extracts the lower 5 bits of mtval (see Table 2).

  –

  badcap = (mtval $>>$ 5) & 0x3f: Extracts bits 5–10 of mtval.

Figure 2. mtval register format for capability exception.

Table 2. Exceptions in CHERI and their impact.

CapCause	Violation	Impact
0x01	Bound Violation	6
0x02	Tag Violation	9
0x03	Seal Violation	8
0x04	Type Violation	9
0x08	Software-defined Permission Violation	5
0x10	GLOBAL Violation	7
0x11	PERMIT_EXECUTE Violation	7
0x12	PERMIT_LOAD Violation	5
0x13	PERMIT_STORE Violation	6
0x14	PERMIT_LOAD_CAPABILITY	7
0x15	PERMIT_STORE_CAPABILITY	7
0x16	PERMIT_STORE_LOCAL_CAPABILITY	7
0x18	PERMIT_ACCESS_SYSTEM_REGISTERS	7
0x19	PERMIT_INVOKE Violation	8
0x1c	PERMIT_SET_CID Violation	9

Moderate impact, Critical impact.

As shown in Table 2, exceptions are categorized into two groups based on their impact score: Critical and Moderate. Critical exceptions trigger an immediate halt of the affected threads through a force-unwind mechanism, ensuring the system is protected from further compromise. In contrast, Moderate exceptions are handled by the proposed exception handler, which performs permission adjustments to enable recovery while maintaining operational integrity. Table 3 summarizes mitigation strategies for moderate-level exceptions.

Table 3. Moderate-level exceptions in CHERI that need mitigation.

CapCause	Mitigation Strategy
0x01	Adjusting capability bounds to valid ranges to restrict access within permissible limits.
0x08	Revoking the violated permissions to ensure the task operates within allowed constraints.
0x10	Removing GLOBAL permission to restrict cross-compartment access and enforce isolation.
0x11	Revoking execute permission, allowing the task to continue without execution rights.
0x12	Restricting read access by revoking load permissions to prevent unauthorized data access.
0x13	Downgrading permissions to read-only, preventing unauthorized write operations.
0x14	Blocking capability loading to prevent unauthorized access to capabilities.
0x15	Preventing capability storage to avoid potential capability forgery or misuse.
0x16	Restricting local capability storage to maintain temporal safety and prevent misuse.
0x18	Denying system register access to protect sensitive system resources from unauthorized use.

Listing 3. CHERIoT-RTOS core scheduler initialization.

• Risk Monitoring—To assess security risks, the system continuously monitors and logs recently triggered exceptions, computing a risk score using two complementary approaches:

  –

  Thread-based monitoring: Exceptions are recorded at the thread level to track the number and type of faults each thread triggers.

  –

  Compartment-based monitoring: Exceptions are recorded per compartment to detect broader fault patterns and evaluate the security posture of each compartment. In CHERI, a compartment is an isolated execution context enforcing strict memory safety via hardware capabilities. Each compartment consists of a Program Counter Capability (PCC) for executing code and accessing read-only data, a Capability Global Pointer (CGP) for mutable global variables, and an import/export interface for secure interactions with other compartments or external resources.

  Regardless of monitoring scope, exception attributes are evaluated to determine criticality:

  –

  Exception Severity: Mapped from the predefined CHERI exception list and its associated impact score (Table 2).

  –

  Exception Frequency: Number of exceptions triggered by a thread or compartment within the current monitoring window.

  –

  Average Exception Interval: Mean time between consecutive exceptions for a given thread or compartment, indicating fault rate.

• Risk Table—At the core of the monitoring algorithm is a risk table that logs exception-related metadata and correlates it with threads or compartments. Key fields include the following:

  –

  Thread/Compartment ID: Unique identifier of the faulting entity.

  –

  CapCause: Cause of the exception as recorded in the mtval register, corresponding to the values in Table 2.

  –

  Count: Total number of exceptions recorded for the entity within the monitoring window (capped by CONFIG_MAX_CHERI_EXCEPTIONS).

  –

  Timestamp: Time of the most recent exception.

  –

  Avg Interval: Average time gap between recent exceptions.

  –

  Window_Start: Start time of the current 5000 ms sliding monitoring window. Exceptions outside this window are discarded, and counts reset at each window rollover.

  The CHERI RTOS operates with statically defined threads and fixed stack sizes. By default, the system supports eight threads, configurable up to 255. In our implementation of thread-based monitoring, the risk table retains records for the 16 most recent threads that have triggered exceptions.
  To accurately present the exception rate in a CHERI-based RTOS, two bounding parameters must be considered:

  –

  Scheduler tick frequency—Typically ranging from 1 to 10 kHz, configurable via the CONFIG_SCHEDULER_TICK_FREQ option in the SDK headers.

  –

  Execution context—Determines how often a faulty thread can trigger exceptions, potentially on every cycle. For example, an infinite loop performing repeated capability violations could generate exceptions at maximum frequency. In practice, hardware watchdogs or compartment-level timeouts (e.g., via thread_sleep) eventually preempt such behavior.

  Table 4 outlines the risk table format, including the size of each entry and the possible value ranges.

Table 4. Risk table format.

Field	Type	Size (Bytes)	Ranges
Thread ID	uint16_t	2	0x01–0xFFFF
CapCause	uint8_t	1	0x01–0x18
Count	uint8_t	1	0–20
Timestamp	uint64_t	8	Timestamp
Avg Interval	uint32_t	4	10–5000 ms

Table 4. Risk table format.

Field	Type	Size (Bytes)	Ranges
Thread ID	uint16_t	2	0x01–0xFFFF
CapCause	uint8_t	1	0x01–0x18
Count	uint8_t	1	0–20
Timestamp	uint64_t	8	Timestamp
Avg Interval	uint32_t	4	10–5000 ms

• Risk Score—The risk score is designed to provide a comprehensive assessment of potential security threats, relying solely on exception severity risks overlooking scenarios in which frequent but less severe exceptions indicate a deeper issue. To address this, we employ a composite equation that integrates multiple exception attributes, yielding a more balanced and accurate risk evaluation.
  Updating the risk table involves the following steps:
  • Record the cause of the newly triggered exception.
  • Increment the exception count for the corresponding thread or compartment.
  • Calculate the time interval between the two most recent exceptions to estimate exception frequency.
  • Update the timestamp to reflect the latest occurrence.
  • Compute $Risk\_Scor{e}_{ID}$ using Equation (1).
  $$RiskScor{e}_{ID}={\displaystyle \frac{\alpha ·I·C}{1+\beta ·A}}$$

  (1)

  where

  –

  $RiskScore\in$ [0, 1]: The risk score that represents the degree of abnormal behavior per thread or compartment.

  –

  $ID$: Task or comportment ID.

  –

  $\alpha \in$ [0.01, 0.1]: A weight parameter that controls the relative importance of the impact score.

  –

  $I\in$ [0, 10]: Impact score or severity score assigned to the exception based on the impact score table.

  –

  $C\in$ [0, 10]: Count of exceptions triggered by a particular thread or compartment.

  –

  $\beta \in$ [0.01, 0.05]: A weighting factor (ranging from 0 to 1) that adjusts the impact of the time interval between exceptions on the risk score.

  –

  $A\in$ [10, 5000 ms]: The average interval represents the time (in milliseconds) between the most recent exception and the preceding one for a specific task.

Tuning the parameters $\alpha$ and $\beta$ is essential to ensuring accurate and context-sensitive risk assessment. These parameters were empirically tuned through sensitivity analysis on synthetic and real exception traces. We varied $\alpha$ within [0.01, 0.1] and $\beta$ within [0.01, 0.05] to calibrate the relative impact of exception severity and temporal frequency on the risk score. Lower $\alpha$ values emphasize tolerance toward severity, while higher $\beta$ values increase the sensitivity to rapid repeat exceptions. Selecting values close to zero leads to near-zero risk scores that diminish the detection sensitivity, while larger values cause disproportionately high-risk scores that may increase false positives. Thus, the chosen moderate ranges balance sensitivity and specificity effectively. This balance helps reduce false positives while maintaining effective detection and mitigation responsiveness. When increased fault severity or frequency is observed, adjusting these parameters enables more aggressive or conservative mitigation aligned with security policy revisions or runtime conditions.

Once the RiskScore for each thread or compartment is calculated, it is compared against two thresholds, x and y, to determine the appropriate system response. These thresholds balance detection sensitivity against false positives and can be tuned according to operational requirements and empirical observations.

$$\begin{array}{cc}\hfill \mathrm{If}\mathrm{Sec}\mathrm{urity}\mathrm{level}=\mathrm{high}\mathrm{alert}& \to 0<RiskScor{e}_{ID}<x\hfill \\ \hfill \mathrm{else}\mathrm{if}\mathrm{Sec}\mathrm{urity}\mathrm{level}=\mathrm{normal}& \to 0<RiskScor{e}_{ID}<y\hfill \\ \hfill & 0<x<y<1\hfill \end{array}$$

We define the threshold parameters as follows:

• x = 0.5 (Middle threshold)—In high-alert mode, any risk score above 0 and below 0.5 triggers mitigation actions, enabling a more sensitive response to potential threats.
• y = 0.7 (Upper threshold)—In normal mode, risk scores below 0.7 trigger mitigation actions, while scores above 0.7 indicate a more severe risk.

If the risk score exceeds 0.5 in high-alert mode or 0.7 in normal mode, the situation is classified as critical. In such cases, the system initiates immediate and severe countermeasures, such as isolating or terminating the offending thread or compartment, regardless of the current security mode.

The core idea of progressive containment is to adapt the strictness of mitigation based on the evolving risk score and violation history. When a moderate-level exception is detected, the framework computes the necessary reduction in capability permissions or bounds, such as a 50% bound shrink as a representative decrement chosen from empirical testing that balances security and system availability. This adaptive approach avoids binary decisions (full termination vs. no action), enabling incremental restriction tailored to the severity and recurrence of violations. Thresholds and percentage reductions are configurable, allowing fine-tuning for different deployment scenarios or security policies.

6.2. Permission Adjustment

In the CHERI protection model, exceptions occur when a thread or compartment attempts an operation that violates its assigned capabilities (permissions). These violations may arise from various causes, and the resulting exceptions serve as a key security mechanism to prevent unauthorized actions. When the risk score determined in the previous step meets or exceeds the threshold for permission adjustment, the algorithm examines the exception cause to determine the appropriate response. It then applies targeted restrictions to the affected capabilities. By enforcing such restrictions dynamically, the system ensures that the task continues operating within its intended security boundaries while minimizing the likelihood of further violations. Table 5 summarizes the potential security violations associated with each exception type and provides guidance on the corresponding permission constraints applied by the proposed model to mitigate malicious or unsafe behavior.

Table 5. Restricting tasks’ permissions to prevent these security breaches.

CapCause	Security Consequence
0x01	Buffer overflows or heap exploitation (Bounds)
0x02	Using unauthorized capabilities (Tag)
0x03	Modifying sealed capabilities (Integrity)
0x04	Performing unauthorized operation (Type)
0x08	Violating software-defined permissions
0x10	Unauthorized memory access
0x11	Unauthorized code execution
0x12	Unauthorized data access
0x13	Unauthorized data modification
0x14	Unauthorized capability leakage
0x15	Privilege escalation attempts
0x16	Unauthorized capability acquisition
0x18	Unauthorized system register modification
0x19	Unauthorized capability usage
0x1c	Unauthorized compartment switching

7. Implementation and Evaluation

We implemented the RPA mechanism on CHERIoT RTOS, an open-source CHERI-based OS for embedded platforms. Our implementation integrates with the CHERIoT-extended LLVM (CHERIoT-clang) toolchain and the FreeRTOS kernel, targeting the CHERIoT-Ibex RISC-V core, which supports hardware-enforced capabilities. Firmware builds are managed through the xmake build system for automated and reproducible compilation and linking. The experimental setup was meticulously designed to ensure consistency and reproducibility, targeting native CHERI-compliant hardware or a cycle-accurate CHERI simulator derived from the CHERI formal specification. Specific toolchain and emulator software versions are documented in the public CHERIoT-Platform GitHub repository (January 2025) to enable external validation and future research extensions. This standardized toolchain provides a stable foundation for integrating CHERI capabilities into FreeRTOS, enabling rigorous evaluation.

Through these experiments, we demonstrated the following key features:

• Continuous Operation: Maintains system functionality during capability violations without requiring full thread termination.
• Precision Security: Selectively revokes permissions (e.g., Execute, Load, Store, and Seal) based on the violation type.
• Progressive Containment: Gradually reduces capability bounds to minimize potential damage.
• Policy-Driven Responses: Enables configurable, context-aware mitigation strategies tailored to the nature of each violation.

7.1. Security Effectiveness Evaluation

To comprehensively evaluate the security effectiveness of the RPA mechanism, a series of fault injection experiments were conducted. These experiments aimed to assess the system’s capability to detect, mitigate, and recover from unauthorized behaviors or access patterns that commonly threaten real-time operating systems. A total of 35 simulated attacks were executed and analyzed. The objective of this evaluation is to determine whether RPA can effectively detect unauthorized activity, revoke dangerous permissions, contain the impact of capability misuse, and ensure system continuity, all while maintaining CHERI’s foundational security guarantees. The assessment focused on four dimensions: the accuracy of detection, the completeness of mitigation, the continuity of execution after a fault, and the containment of potential damage.

In total, 40 simulated attack scenarios were tested and analyzed, then categorized into two distinct groups.

• Twenty real-world CVEs: These vulnerabilities, listed in Table 6, were selected for their relevance to FreeRTOS and similar platforms. Each was modeled and executed on both a standard FreeRTOS system and our RPA-enhanced CHERIoT system. This approach allowed us to directly compare baseline and mitigated behaviors.

Table 6. CVE coverage: FreeRTOS vs. proposed RPA framework.

CVE ID	FreeRTOS	Proposed RPA
CVE-2018-16522	Privilege escalation	✓
CVE-2018-16523	Data corruption or DoS	✓
CVE-2018-16524	Data corruption or crash	✓
CVE-2018-16525	Remote code execution	✓
CVE-2018-16526	System crash, DoS	✓
CVE-2018-16527	Information leak	✓
CVE-2018-16528	Remote code execution	✓
CVE-2018-16598	Memory corruption	✓
CVE-2018-16599	Memory disclosure	✓
CVE-2018-16600	Memory disclosure	✓
CVE-2018-16601	Memory disclosure	✓
CVE-2018-16602	Memory disclosure	×
CVE-2018-16603	Memory disclosure	×
CVE-2019-13120	Code execution	✓
CVE-2021-31571	Privilege escalation	✓
CVE-2021-31572	Privilege escalation	✓
CVE-2021-32020	Privilege escalation	✓
CVE-2021-43997	Memory disclosure	✓
CVE-2024-28115	Stack-based buffer overflow	✓
CVE-2024-38373	Arbitrary code execution	✓

Table 6. CVE coverage: FreeRTOS vs. proposed RPA framework.

CVE ID	FreeRTOS	Proposed RPA
CVE-2018-16522	Privilege escalation	✓
CVE-2018-16523	Data corruption or DoS	✓
CVE-2018-16524	Data corruption or crash	✓
CVE-2018-16525	Remote code execution	✓
CVE-2018-16526	System crash, DoS	✓
CVE-2018-16527	Information leak	✓
CVE-2018-16528	Remote code execution	✓
CVE-2018-16598	Memory corruption	✓
CVE-2018-16599	Memory disclosure	✓
CVE-2018-16600	Memory disclosure	✓
CVE-2018-16601	Memory disclosure	✓
CVE-2018-16602	Memory disclosure	×
CVE-2018-16603	Memory disclosure	×
CVE-2019-13120	Code execution	✓
CVE-2021-31571	Privilege escalation	✓
CVE-2021-31572	Privilege escalation	✓
CVE-2021-32020	Privilege escalation	✓
CVE-2021-43997	Memory disclosure	✓
CVE-2024-28115	Stack-based buffer overflow	✓
CVE-2024-38373	Arbitrary code execution	✓

• Fifteen abstract vulnerability classes: To assess generalizability, we synthesized attacks representing common exploitation techniques (e.g., stack smashing, heap spraying, and privilege escalation). These are summarized in Table 7 and were executed exclusively on the RPA-enhanced system.

Table 7. Summary of custom vulnerability pattern test results.

Vulnerability	FreeRTOS	Proposed RPA
Stack smashing	Overwrites return address	Stack bounds enforced
Pointer overwrite	Arbitrary code execution	Indirect calls restricted
Double free	Heap corruption	Capability invalidation free
Format string	Memory disclosure	Memory access restricted
Integer overflow	Buffer overflow	Bounds check enforced
Data exfiltration	Sensitive data leak	Memory sealing compartments
Race condition	Data race, privilege escalation	Fine-grained compartments
TOCTOU	Privilege escalation, data race	Unforgeable checked capabilities
Task hijacking	Malicious code execution	Task isolation compartments
Stack overflow	System crash, code execution	Stack bounds enforced
Buffer over-read	Information leak	Readable memory restricted
Memory leak	Resource exhaustion, DoS	Capabilities tracked revoked
ROP	Code reuse attack	Arbitrary execution prevented
Heap spraying	Increases exploit reliability	Forged pointers prevented
Task starvation	Denial of service	Fine-grained scheduling

Table 7. Summary of custom vulnerability pattern test results.

Vulnerability	FreeRTOS	Proposed RPA
Stack smashing	Overwrites return address	Stack bounds enforced
Pointer overwrite	Arbitrary code execution	Indirect calls restricted
Double free	Heap corruption	Capability invalidation free
Format string	Memory disclosure	Memory access restricted
Integer overflow	Buffer overflow	Bounds check enforced
Data exfiltration	Sensitive data leak	Memory sealing compartments
Race condition	Data race, privilege escalation	Fine-grained compartments
TOCTOU	Privilege escalation, data race	Unforgeable checked capabilities
Task hijacking	Malicious code execution	Task isolation compartments
Stack overflow	System crash, code execution	Stack bounds enforced
Buffer over-read	Information leak	Readable memory restricted
Memory leak	Resource exhaustion, DoS	Capabilities tracked revoked
ROP	Code reuse attack	Arbitrary execution prevented
Heap spraying	Increases exploit reliability	Forged pointers prevented
Task starvation	Denial of service	Fine-grained scheduling

To strengthen the statistical rigor of our evaluation, each simulated attack scenario was executed across multiple independent runs (minimum 10 iterations per test case) to capture variability in detection and mitigation outcomes. For each test, we computed statistical measures including the mean detection accuracy, mitigation completeness, and execution continuity, along with their variances. Confidence intervals at the 95% level were calculated for key metrics to ensure results are statistically significant and robust to execution variability. This rigorous approach allows us to reliably assess the effectiveness and consistency of the RPA framework in mitigating diverse attack patterns.

The first set of tests focused on 20 CVEs. For example, CVE-2018-16522 is detailed in Listing 4. These vulnerabilities were selected for their significance to embedded systems and for illustrating specific weaknesses in FreeRTOS. Each vulnerability was modeled within a test environment and evaluated under both FreeRTOS and the proposed RPA-enabled CHERIoT system. The comparative results are summarized in Table 6. As anticipated, FreeRTOS demonstrated no built-in defenses against any of the 20 vulnerabilities tested. In each instance, exploitation was successful without detection or containment, resulting in issues such as privilege escalation, remote code execution, data corruption, or memory disclosure. In contrast, the proposed RPA framework effectively mitigated 18 of the 20 vulnerabilities by dynamically revoking high-risk permissions (e.g., Execute and Store), implementing spatial containment through a 50% reduction in capability bounds, and ensuring task-level isolation within compartment boundaries.

Listing 4. CVE-2018-16522.

Two vulnerabilities, CVE-2018-16602 and CVE-2018-16603 were only partially mitigated. These involved memory disclosure attacks that the RPA framework successfully detected and addressed by revoking Load permissions and applying spatial containment. However, complete mitigation, which would encompass total memory erasure or data sealing, necessitates hardware-level data sanitation features that are not yet present in the current CHERIoT implementation. Despite this limitation, the framework effectively prevented further unauthorized access following the initial violation, significantly reducing residual risk.

This partial mitigation highlights a critical limitation: residual sensitive data may remain accessible without advanced hardware-assisted sanitization. While the framework effectively contains the immediate impact of disclosure, it cannot guarantee complete memory sanitization in its current form, leaving this challenge to future work. Promising directions include integrating hardware-assisted sanitization techniques into capability architectures, such as the segment folding and shadow memory encoding techniques exemplified by GiantSan [73], and architectural support for efficient data sanitization demonstrated by Evanesco et al. [74]. These emerging mechanisms aim to provide efficient, low-overhead, and scalable sanitization, thereby strengthening defenses against residual data leakage and advancing the security guarantees of capability-based RTOS designs like CHERIoT.

The second phase of testing involved a focused set of 15 custom-designed test cases, each corresponding to a generalized vulnerability class commonly observed in embedded and real-time systems. These cases were not derived from specific CVEs but were constructed to simulate prevalent exploitation techniques, including stack smashing, pointer overwrites, double-free bugs, race conditions, memory disclosure, and code-reuse attacks (such as return-oriented programming and heap spraying). Each pattern was implemented at the kernel level and triggered through deliberate fault injections utilizing memory manipulation, capability misconfiguration, and race-inducing delays. This setup facilitated a realistic evaluation of the proposed RPA framework’s response under targeted exploit conditions.

As summarized in Table 7, FreeRTOS does not possess any native mechanisms for detecting or preventing these vulnerabilities. In contrast, the RPA-enhanced system effectively mitigated all 15 classes of attacks. For instance, stack smashing was contained through enforced bounds on stack capabilities, while pointer overwrites were mitigated by disabling indirect calls on suspect capabilities. Double-free vulnerabilities triggered immediate capability invalidation, and memory disclosure vectors—such as format strings or buffer over-reads—were restricted through enforced access policies and compartment sealing.

In 14 out of 15 cases, the affected thread was able to continue execution in a degraded but safe state following mitigation. The exception occurred during repeated forged pointer injection, where the violation reoccurred rapidly, surpassing the threshold defined in the policy escalation logic. In this instance, the system responded by safely terminating the compromised thread. This behavior demonstrates the effectiveness of RPA’s multi-stage policy model, which applies containment for isolated faults while escalating response severity in cases of persistent or potentially malicious activity. In contrast, the standard CHERI approach terminates all threads.

7.2. Runtime Overhead and Availability Valuation

While security is a critical objective in embedded systems, it must be carefully balanced with system availability and performance, particularly in real-time and safety-critical environments. This section evaluates the runtime efficiency and operational continuity of the proposed RPA framework. Specifically, we investigate whether the integration of dynamic mitigation logic affects task responsiveness or introduces significant system downtime under fault conditions. To this end, a series of benchmark experiments were conducted under controlled violation scenarios. Each test case was executed across three system configurations: baseline FreeRTOS, default CHERIoT-RTOS (without adaptive mitigation), and the proposed RPA-enhanced CHERIoT. The evaluation focused on three primary metrics: thread continuation rate, violation handling time, and total system downtime. A summary of the results is provided in Table 8.

Table 8. System availability and violation handling overhead across configurations.

Metric	FreeRTOS	CHERIOT	RPA
Thread Continuation Rate	100%	0	92%
Violation Handling Time	0.8 $\mu$s	0.5 $\mu$s	2.3 $\mu$s
System Downtime	0 s	18.4 s	0.9 s

In terms of thread continuation, FreeRTOS achieved a 100% rate, which is somewhat misleading, as it lacks mechanisms to detect or block violations. Consequently, all faults can propagate unchecked, potentially resulting in memory corruption or unauthorized code execution. In contrast, the default CHERIoT environment terminates any thread involved in a capability violation, resulting in a 0% continuation rate. While this approach ensures strict isolation, it can lead to significant availability loss. The RPA methodology offers a balance between these two extremes. By implementing targeted mitigations instead of thread termination, the system maintained thread execution in 92% of the tested violation scenarios. Thread termination was only initiated in cases of repeated or unrecoverable violations, in accordance with predefined escalation policies.

The third key metric, system downtime, represents the cumulative execution time lost due to halts or delays in recovery triggered by violations. The default CHERIoT recorded 18.4 s of downtime during our test cycle, primarily due to repeated thread terminations and reinitializations. In contrast, the RPA-enhanced system reduced downtime to only 0.9 s, reflecting a 95% improvement by enabling most threads to recover dynamically following fault mitigation. FreeRTOS demonstrated no downtime under similar scenarios, but this outcome is a result of its inability to detect or respond to violations, rather than an indication of its resilience.

By comparison, formally verified microkernels such as seL4 offer strong isolation and reliability guarantees through comprehensive formal verification. seL4 is designed to provide minimal and predictable system downtime, with mathematically proven correctness ensuring fault containment and deterministic behavior in real-time environments. While seL4 focuses on providing a minimal trusted kernel with rigorous correctness proofs, our RPA framework complements this by enabling adaptive, capability-based mitigations that preserve thread execution and reduce downtime in CHERI-enabled RTOSs. This comparison highlights different but complementary approaches for balancing security and high availability in modern embedded systems.

To further understand how RPA responds to specific types of faults, we evaluated continuity across the four main categories of capability violations: Execute, Load, Store, and Seal. These categories were tested individually under CHERIoT and RPA configurations, and the outcomes are detailed in Table 9. As expected, default CHERIoT halted execution in every case. In contrast, the RPA framework successfully handled all four violation types by selectively removing the corresponding permissions and shrinking capability bounds, enabling safe continuation of execution in each case.

Table 9. Execution continuity after capability violations.

Violation Type	CHERIoT	RPA
Execute Violation	×	✓
Load Violation	×	✓
Store Violation	×	✓
Seal Violation	×	✓

In addition to these core performance metrics, implementation data confirms that the RPA mechanism incurs minimal resource overhead. The inclusion of mitigation logic and policy enforcement code increased the binary size by only 2.1 kilobytes, representing approximately 0.8% of the baseline system image. The memory usage required to store risk evaluation tables and policy metadata added just 0.9 kilobytes to the runtime footprint. Finally, system scheduling behavior remained virtually unaffected; worst-case task response time increased by less than 0.1%, which falls well below thresholds of concern for real-time scheduling policies.

Violation handling time was assessed to determine the runtime cost associated with implementing dynamic mitigations. FreeRTOS, which does not conduct violation checks, exhibited an average overhead of 0.8 microseconds per memory access during stress testing. The default CHERIoT, which is equipped with hardware-enforced exception traps, demonstrated a lower latency of 0.5 microseconds due to its immediate termination strategy. The proposed RPA model introduced a modest increase in latency, averaging 2.3 microseconds per violation event. This additional cost can be attributed to the logic required for policy evaluation, capability adjustment, and containment enforcement. Nevertheless, this increase remains within acceptable limits for real-time systems and is offset by significant gains in system continuity. While the measured latency increase is minimal in our experiments, scalability to larger multi-core and distributed IoT platforms is an important consideration. The modular design of the RPA framework supports parallelized risk evaluation and localized mitigation enforcement across cores, minimizing synchronization overhead. Moreover, the low resource requirements and near-zero impact on scheduling behavior indicate strong potential for scalability in complex, multi-core IoT environments. Ongoing and future work will focus on quantitatively evaluating scalability performance and optimizing coordination mechanisms to ensure robustness and efficiency on heterogeneous processing architectures.

8. Conclusions

This paper introduces a novel, adaptive security framework for CHERI-enabled RTOSs, addressing the challenges of protecting real-time embedded systems against memory-based and privilege-based attacks. By continuously monitoring CHERI-triggered exceptions, computing a dynamic risk score, and applying targeted permission adjustments, the proposed RPA framework effectively detects and mitigates security threats while preserving system functionality. Notably, the RPA framework maintains thread execution in 92% of tested violation scenarios, demonstrating a significant improvement in system availability by avoiding unnecessary thread termination. Experimental evaluation demonstrates that the RPA-enhanced CHERIoT system mitigates most tested vulnerabilities, including both real-world CVEs and generalized attack patterns, while maintaining continuous operation for most threads. Runtime overhead remains low and within acceptable limits for real-time applications, and system downtime is drastically reduced compared to default CHERIoT behavior. These results validate the finding that strong security enforcement can be integrated into RTOS environments without compromising performance or availability. Beyond these technical achievements, this framework has significant implications for IoT safety-critical deployments. Enhancing the resilience and reliability of embedded systems is essential in healthcare, where secure device operation directly impacts patient safety and privacy. In Industrial Control Systems and manufacturing, robust protections reduce risks of costly operational disruptions and safety hazards. Furthermore, smart city infrastructures, including traffic management, energy distribution, and public transportation, rely on a secure and continuous system functioning well to maintain public safety and service quality. Overall, the proposed RPA framework advances the state of the art in embedded system security by balancing performance, security, and availability. It lays a foundation for deploying more resilient IoT systems in increasingly complex and interconnected environments, where safety-critical applications demand both strong security assurance and real-time operational guarantees.

9. Future Direction

This work establishes a foundation for resilient and adaptive embedded systems; however, the evolving threat landscape and growing system complexity demand continued advancement. In the short term, our research will focus on developing machine learning-driven risk scoring models that anticipate vulnerabilities and support real-time, adaptive security policy adjustments, thereby strengthening proactive threat responses under system constraints. We will also pursue the formal verification of dynamic security policies to rigorously ensure correctness, reliability, and certification in safety-critical domains such as aerospace, automotive, and medical systems. Looking further ahead, longer-term directions will be crucial to realizing fully autonomous cyber–physical system security. These include exploring cross-layer mechanisms for mixed-criticality systems that coordinate protection across hardware, kernel, and application layers; designing scalable, energy-efficient solutions for secure IoT environments—particularly across multi-core and distributed platforms with energy-aware requirements; and progressively integrating adaptive and formally verified mechanisms into self-optimizing security frameworks that maintain robust operation in resource-constrained environments.