Resolving Availability and Run-time Integrity Conflicts in Real-Time Embedded Systems

TL;DR

The paper tackles the conflict between availability and run-time integrity in real-time embedded systems without MMUs. It introduces PAIR, a hardware-assisted monitor that maintains an Availability Region ($AR$) of safe tasks and aborts only violating tasks via a non-maskable interrupt, allowing non-violating tasks to continue. The design is specified with LTL, formally verified using NuSMV, and implemented as FSM-based hardware with an open-source FPGA prototype on openMSP430 and RIOT, incurring minimal overhead (about $+2.3\%$) and no per-task runtime cost. This work provides a practical approach for ensuring timely, deterministic behavior on low-end MCUs while preserving both availability and run-time integrity in the presence of runtime violations.

Abstract

Run-time integrity enforcement in real-time systems presents a fundamental conflict with availability. Existing approaches in real- time systems primarily focus on minimizing the execution-time overhead of monitoring. After a violation is detected, prior works face a trade-off: (1) prioritize availability and allow a compromised system to continue to ensure applications meet their deadlines, or (2) prioritize security by generating a fault to abort all execution. In this work, we propose PAIR, an approach that offers a middle ground between the stark extremes of this trade-off. PAIR monitors real-time tasks for run-time integrity violations and maintains an Availability Region (AR) of all tasks that are safe to continue. When a task causes a violation, PAIR triggers a non-maskable interrupt to kill the task and continue executing a non-violating task within AR. Thus, PAIR ensures only violating tasks are prevented from execution, while granting availability to remaining tasks. With its hardware approach, PAIR does not cause any run-time overhead to the executing tasks, integrates with real-time operating systems (RTOSs), and is affordable to low-end microcontroller units (MCUs) by incurring +2.3% overhead in memory and hardware usage.

Figures (10)

• Figure 1: PAIR Overview: Tasks and an RTOS execute in software, with all tasks initially in the AR. After detecting an integrity violation (1), PAIR triggers the trampoline into RTOS to kill-and-yield (2) and removes the violating task from AR (3). Only after a trusted software update has completed (4) will PAIR reinstate the violating task into AR (5).
• Figure 2: System Configuration: PAIR interfaces with the MCU to read specific signals pertaining to the currently executing instruction (e.g., $PC$, $W_{en}$, $R_{en}$, $D_{addr}$, $irq$).
• Figure 3: PAIR security properties.
• Figure 4: Axiom: Tracking currently executing task.
• Figure 5: Sub-properties to monitor task execution.