Deploying Linux in Safety Critical Applications - Three Key Challenges

### Overview Chris Temple, a lead safety and reliability system architect working at Arm in Germany, discusses the core challenges of enabling Linux in safety-critical applications within the context of the open-source ELISA project. The mission of ELISA is to enable Linux in safety applications rather than providing a safety-conforming kernel off the shelf. Temple explains the crucial distinction between safety (the experienceable absence of unreasonable risk) and conformance (adherence to standards like ISO 26262). While standards specify safety integrity levels (such as ASIL A through D) to set the required degree of engineering rigor and evidence, conformance alone does not guarantee safety. Safety engineering relies on defining safety claims, satisfying them with appropriate rigor, and assembling a structured safety case.

### Key Topics To analyze how an operating system must behave safely without analyzing every bespoke downstream workload, Temple introduces a simple system model containing three layers: applications, the operating system, and hardware. Each layer maintains a context and provides services to ensure timely progress. - **Timing**: Solved through established software techniques (such as deadline monitoring) and hardware implementations (such as clock monitoring circuits, redundant oscillators, and RC-based frequency checks). - **Hardware Context**: Protected using privilege-based security architectures (e.g., in Arm or x86) and safety-enabled hardware features such as split-lock cores, safety islands, ECC/parity bits on SoC data paths, memory BIST, and scan diagnostics. - **Application and OS Context Integrity**: The central challenge is ensuring the operating system does not corrupt application, OS, or hardware contexts in an undetected dangerous way, and preventing applications from corrupting each other or system software.

### Technical Details Temple evaluates several solution "knobs" available to address OS and context corruption: - **Alternative Kernel Choice**: While microkernels (e.g., QNX, VxWorks) and separation kernels (e.g., Integrity, Lynx) offer strong isolation by design, they suffer from performance trade-offs and are not off-the-shelf Linux, which is the primary objective of the ELISA project. - **Hardening Linux**: Involves feature stripping/scope reduction, inline checking, and context signing. However, stripping features risks losing what makes Linux valuable, while software-based inline verification and context signing introduce heavy runtime performance overhead. - **Correct-by-Construction Testing**: Testing software extensively to prove high integrity has no runtime overhead, but standards (like ISO 26262) recommend patterns such as single entry/exit points, restricted pointers, and no unconditional jumps to avoid state-space explosions. Linux's complexity makes exclusive reliance on testing unrealistic. - **Exploiting Application Properties**: Structuring safety arguments around application characteristics. Applications fall along a spectrum: - *Class L (Low Safety Complexity)*: Systems with high low-pass filtering characteristics where transient faults are non-critical, fault-tolerance times are long, humans remain in the loop, and end-to-end plausibility checks exist (e.g., automotive In-Vehicle Infotainment telltales up to ASIL B). - *Class H (High Safety Complexity)*: Systems where transient faults are critical, fault-tolerance reaction windows are milliseconds, no human loop exists, and mixed criticality up to ASIL D is required (e.g., autonomous driving systems).

### Takeaways & The Integration Challenge Temple highlights the integration challenge of assembling multiple Safety Elements out of Context (SEooC). Components supplied with safety manuals rely on specific context assumptions and assign integration requirements ("assumptions of use") to the system integrator. Integrators must verify these assumptions, confirm safety claims remain intact, prevent previous safety properties from vanishing, and ensure no new failure modes emerge. Because an autonomous driving ECU can quickly involve over 100 safety elements, arguments must remain manageable rather than relying on endless assumptions. Ultimately, there is no single "killer argument" or silver bullet for running Linux in safety-critical systems; success requires assembling and balancing complementary puzzle pieces across hardware, kernel hardening, testing, and application constraints.