The Hidden Risks of Using Linux in Aviation Systems

I. Introduction

II. Why Linux Seems Attractive for Avionics

III. What Airworthiness Really Requires

IV. Core Limitations of Linux in Safety-Critical Avionics

Figure 1.

Figure 1.

A. Open System Semantics with Unpredictable Behavior

Linux exhibits inherent open-world system semantics, characterized by a vast, dynamically evolving set of execution paths whose behavior is shaped by runtime operating conditions, workload characteristics, and autonomous interactions among core kernel subsystems. These execution paths arise from multiple independent kernel mechanisms—including asynchronous kernel threads, memory reclaim and page table mutations, interrupt cascades and softIRQ execution, NUMA rebalancing, and RCU state transitions—that operate independently of application intent and cannot be enumerated, frozen, or formalized at system integration time. The combined effect of these mechanisms results in an unbounded, non-enumerable system state space, driven by hardware events, concurrent execution, dynamic memory pressure, and load-dependent scheduling, which defies closed-form formal analysis and static verification. This core design attribute stands in direct opposition to ARINC 653’s architectural philosophy, which mandates closed, finitely analyzable system semantics at integration time: all partition schedules are fixed, memory regions are statically allocated, inter-partition communication is deterministic, and dynamic execution path creation is prohibited, constraining the separation kernel to a small, finite, and fully analyzable state machine. Linux’s semantic openness is the root cause of its subsequent temporal and spatial isolation failures, as it inherently precludes the static, bounded, and fully verifiable behavior required for high-integrity DAL A/B avionics systems.

Figure 2. Semantic unfreezing.

Figure 2. Semantic unfreezing.

B. Lack of Temporal Determinism

Deterministic execution requires that the system provide analyzable upper bounds on thread release latency, dispatch delay, kernel service time, and interference from other software components. The Linux process–thread execution model cannot provide such guarantees because scheduling decisions, interrupt handling, and kernel activity are driven by dynamically evolving workload, subsystem state, and asynchronous events. As a result, neither processes nor threads can be associated with a statically provable worst-case response time.

Figure 3. Execution Path comparison.

Figure 3. Execution Path comparison.

In Linux, temporal nondeterminism arises from two architecturally distinct mechanisms whose effects on execution timing must be analyzed separately. Although both may ultimately manifest as preemption or execution delay, their underlying causes, triggering conditions, and analyzability properties are fundamentally different.

1) Scheduler-Driven Nondeterminism

Priority-based scheduling in Linux does not guarantee immediate execution for a runnable high-priority task because scheduling behavior depends on the dynamic state of the system, including run-queue composition, wakeup patterns, migration decisions, and internal kernel bookkeeping. These behaviors occur even in the absence of external events.

Furthermore, the Linux kernel contains numerous non-preemptible regions, such as:

• spinlock-protected critical sections,
• per-CPU data updates,
• scheduler state transitions, and
• low-level exception-handling paths.

While these sections execute, preemption is explicitly disabled, preventing the scheduler from dispatching a higher-priority process or thread until the critical section completes. The duration of these regions is runtime-dependent and influenced by cache state, lock contention, and microarchitectural factors, making their worst-case execution time analytically unbounded.

Thus, synchronous nondeterminism originates from Linux’s time-sharing scheduling model combined with variable-length non-preemptible kernel paths, independent of any asynchronous device or kernel events.

Figure 4.

Figure 4.

2) Event-Driven (Asynchronous) Nondeterminism

Separate from scheduler-driven effects, Linux also contains multiple asynchronous execution sources—including hardware interrupts, softirq processing, network-stack activity, timer callbacks, memory-reclaim operations, and background kernel threads. These activities are triggered by external stimuli or internal system conditions and may occur at arbitrary times. As such, they can preempt a running task immediately (e.g., an interrupt) or occupy CPU time through deferred work (e.g., softirq/ksoftirqd), introducing additional timing variability that cannot be bounded statically.

Asynchronous nondeterminism therefore reflects the open-world, event-driven nature of the kernel’s interaction with devices, resource pressure, and subsystem events—factors inherently outside the scheduler’s deterministic control.

In contrast, ARINC 653-compliant platforms use a predefined major/minor-frame scheduling model with fixed, deterministic execution windows for all subsystems, eliminating runtime jitter from unconstrained events. The timing behavior of Linux versus ARINC 653 is illustrated in Fig. 3.

Figure 5. Scheduling determinism.

Figure 5. Scheduling determinism.

C. No Physical Memory Isolation

A certifiable airborne system must ensure strict physical memory isolation so that the memory assigned to a safety-critical partition cannot be altered, accessed, or affected by other software components at runtime. DO-178C and partitioned-kernel architectures (e.g., ARINC 653) assume that the integrity of a partition’s memory region is preserved by static, hardware-enforced address mappings and that these mappings remain stable across the system’s operational life.

In contrast, Linux relies on a dynamic and mutable virtual-memory architecture that violates these assumptions. The kernel continuously modifies page-table entries, memory mappings, and physical-page ownership as part of normal operation. Several core mechanisms illustrate this behavior:

• Demand paging and on-demand allocation. Page tables are populated lazily, and physical pages may be allocated, remapped, or reclaimed during runtime based on memory pressure and process behavior.
• Page reclaim and compaction. Under memory pressure, the kernel evicts or relocates physical pages, invoking reclaim, compaction, or write-back paths that modify page-table mappings without application involvement.
• Dynamic page-table updates and TLB shootdowns. Linux frequently updates page attributes, permission bits, and mapping structures, triggering cross-CPU TLB invalidations and modifying the effective physical-memory layout during operation.
• Shared kernel-memory structures. The kernel’s slab allocators, per-CPU buffers, and driver subsystems allocate and free kernel memory dynamically; these regions are globally shared and not partition-scoped.

Figure 6.

Figure 6.

Because Linux performs these modifications autonomously, a process or thread cannot be associated with a fixed, statically provable physical-memory region. No mechanism prevents the kernel from reassigning or altering physical pages that lie within or adjacent to the memory range used by a safety-critical application, nor does Linux provide hardware-enforced barriers preventing other components from accessing or corrupting those regions.

Figure 7.

Figure 7.

Consequently, Linux cannot establish the immutable physical-memory boundaries required for DO-178C DAL A/B and cannot meet the spatial-isolation guarantees expected of ARINC 653-style partitioning systems. The kernel’s dynamic memory-mapping semantics inherently preclude the formation of independently verifiable, physically isolated memory partitions.

Thus, Linux’s dynamic page-table management fundamentally conflicts with the DO-178C requirement that a partition’s physical memory be statically allocated, hardware-isolated, and invariant throughout system operation.

Figure 8. Memory mapping drift.

Figure 8. Memory mapping drift.

E. Lack of Fault Isolation

Linux does not provide certifiable inter-process fault containment. All user processes ultimately depend on a single, shared, monolithic kernel, and this kernel is responsible for handling every system call, interrupt, memory-management action, driver interaction, and scheduling decision. Because all processes share the same privileged kernel address space and kernel-resident global structures, a fault in any process can corrupt kernel state that is globally visible and globally trusted.

Figure 9.

Figure 9.

In practice, this means that a defect in one component may propagate through:

• shared kernel memory regions used by subsystems such as the scheduler, VFS, networking, and memory management;
• global locks and synchronization primitives that serialize access across unrelated components;
• reference counters and object life-cycle structures (e.g., file descriptors, network buffers, slab objects);
• interrupt-handling and softirq pathways, whose execution contexts are shared across all processes regardless of their criticality.

Figure 10.

Figure 10.

Since these structures are not partition-scoped—and cannot be restricted or made private to individual processes—Linux cannot prevent a fault originating in one process, or one driver, from affecting the execution correctness, timing, or stability of others. This propagation mechanism is inherent to monolithic-kernel design and directly contradicts the hardware-enforced spatial isolation and partition-level fault containment required for DAL A/B airborne software under ARINC 653.

Commercial avionics RTOS products implementing ARINC 653 adopt the opposite model. They enforce strict partition boundaries using:

• hardware Memory Management Unit (MMU) isolation with statically defined, non-overlapping physical memory regions;
• a minimal, rigorously verified separation kernel responsible only for scheduling partitions and mediating controlled IPC;
• complete disallowance of shared kernel-writable global state between partitions;
• fault-containment boundaries that ensure a failure inside one partition cannot corrupt the separation kernel or any other partition.

As a result, ARINC 653 systems achieve true inter-partition fault isolation, with failures strictly contained to the originating partition. This property is fundamental to satisfying DO-178C/DO-297 fault-propagation analysis for DAL A/B functions.

Figure 11. Kernel containing driver.

Figure 11. Kernel containing driver.

G. Continuous Patch Stream Destabilizes Certified Baselines

Linux evolves at a rapid pace, and maintaining a stable, certifiable baseline is fundamentally incompatible with this development model. Kernel updates are continuous and unavoidable because Linux must support a vast hardware ecosystem, address frequent security vulnerabilities, and resolve behavioral regressions across numerous subsystems. These patches routinely modify core kernel semantics, including:

• locking primitives
• interrupt and softirq threading
• scheduling heuristics
• preemption and concurrency models

For safety-critical software, DO-178C requires that once a baseline is selected, its behavior must remain frozen, repeatable, and fully traceable throughout certification. Any change to that baseline—no matter how small—invalidates prior verification evidence and triggers the DO-178C change-management process: impact analysis, regression testing, artifact updates, and re-establishment of linkage between requirements, design data, and test results. A kernel that changes frequently cannot satisfy this expectation.

An additional complication is that PREEMPT_RT, the component most relevant for deterministic behavior, is itself still under active refinement. Because its design continues to evolve—in areas such as sleeping spinlocks, threaded interrupts, low-latency code paths, and real-time scheduler behavior—maintainers must regularly modify the underlying kernel infrastructure. As upstream RT support matures, new patches inevitably alter timing behavior, locking rules, and execution semantics. This creates semantic churn directly within the parts of the kernel that would be most critical to a certifiable real-time baseline. In practice, this means any attempt to “freeze” a PREEMPT_RT-based Linux kernel will quickly diverge from upstream and will require ongoing, high-cost revalidation.

Figure 12.

Figure 12.

By contrast, commercial avionics kernels intentionally maintain frozen, long-lived baselines, applying only narrow, tightly controlled corrective patches under strict configuration control. Their architectures and processes are specifically optimized to meet DO-178C requirements for version stability, reproducibility, and long-term maintainability—conditions that Linux’s continuous patch stream cannot meet for DAL A/B certification.

H. Complex Toolchain Imposes Prohibitive DO-330 Qualification Burden

Linux relies on a broad and deeply layered toolchain ecosystem that includes compilers, linkers, meta-build systems, configuration generators, device-tree compilers, package utilities, and numerous scripting tools. This ecosystem is structurally different from avionics development environments, both in scale and in the number of transformations that occur between source and final binaries.

Even if all tool versions were frozen, DO-330 requires qualification for every tool that can affect airborne software, as well as for each transformation stage that generates derived artifacts. Linux’s build process depends on dozens of such tools—GCC/LLVM, binutils, kbuild, Kconfig, autotools, CMake, Yocto, Device Tree(DT) compilers, Python and shell-based code generators, pkg-config, ninja, and many others. Each participates in multiple stages of the build pipeline, producing intermediate files, scripts, headers, configuration databases, or hardware description blobs consumed by the kernel.

Figure 13. TCB & Toolchain: The Certification Cost Curve.

Figure 13. TCB & Toolchain: The Certification Cost Curve.

Under DO-330, each tool and each interaction between tools must be justified or qualified, and the scope scales combinatorially. This creates an immense qualification envelope that is economically infeasible for DAL A/B programs — even before considering version churn.

In contrast, avionics RTOS environments deliberately employ minimal, deterministic, and long-term-stable toolchains. A single vendor-qualified compiler, along with a simple assembler and linker, constitutes the entire TQL surface. No meta-build layers, no automatic generators, and no distribution-level tool dependencies exist. This architectural discipline keeps DO-330 qualification tractable and prevents toolchain evolution from destabilizing certified baselines.

V. Common Misunderstandings and Why They Fail

C. Cgroups Provide Partition–Equivalent Isolation

Linux control groups (cgroups) offer mechanisms for resource shaping, but they do not—and cannot—provide the architectural, temporal, or spatial guarantees required for ARINC 653-style safety-critical partitioning. Partitioning in ARINC 653 is a hardware-enforced isolation model, whereas cgroups operate entirely within a shared monolithic Linux kernel. As a result, cgroups cannot achieve deterministic execution, physical memory isolation, or fault containment.

The following sections explain why cgroups fundamentally lack the properties required for certified partitions.

1). Inadequate CPU Time Management

a) Cgroups control only long-term average CPU usage, not fixed execution windows

CPU quota and share controllers influence average CPU distribution over time but do not provide exclusive, deterministic execution windows.

b) Execution order is nondeterministic

Task dispatch in Linux remains governed by the general-purpose scheduler. Its behavior depends on:

• run-queue state
• wakeup timing
• load balancing
• kthread activity
• interrupt/softirq interference

This makes execution order nondeterministic and non-provable, violating DO-178C DAL A/B WCET requirements.

c) Tasks can be preempted or interrupted at any time

Even with cgroups, tasks may be paused by:

• interrupts
• softirq execution
• RCU callbacks
• memory reclaim
• kworkers
• driver activity

Thus, a cgroup cannot guarantee exclusive, interference-free execution, which ARINC 653 partitions explicitly guarantee within their time windows.

2). Inadequate Memory Space Management

a) Cgroups limit the amount of memory, but do not reserve a fixed memory allocation

Memory cgroups apply quota-based limits (e.g., memory.max) that constrain how much memory a group may consume.

However, they do not provide a statically reserved memory allotmen. A task in a cgroup:

• is not guaranteed a specific minimum amount of available memory,
• does not receive memory pre-allocated at system initialization, and
• cannot rely on invariant memory availability during execution.

Thus, a cgroup’s memory limit represents a ceiling, not a reservation.

b) Cgroups do not define any fixed or exclusive memory address ranges

Even when a cgroup’s memory usage is limited, the kernel remains free to assign any virtual or physical page from the global memory pool. Cgroups do not define:

• specific virtual address regions,
• exclusive physical memory ranges, or
• hardware-protected, partition-specific address mappings.

Pages belonging to a cgroup may be:

• allocated from any NUMA node,
• reclaimed under pressure,
• compacted or migrated by the kernel,
• remapped due to page-table updates, or
• affected by global MM subsystem activity.

Therefore, cgroups provide only logical memory accounting, not physical memory isolation.

3). Shared Kernel Prevents Fault Containment and Interference Freedom

Even if cgroups isolate user-space processes logically, they do not isolate kernel-space activity, because:

all cgroups share the same kernel address space,

all system calls execute inside the same kernel instance,

all drivers run with full privilege inside shared global state,

interrupts and kernel threads serve all cgroups uniformly.

This means:

a driver fault can corrupt kernel global state,

a scheduling bug can stall all tasks,

memory pressure caused by one cgroup can trigger reclaim affecting others, RCU stalls or deadlocks propagate across the entire system.

4). Why ARINC 653 Partitions Can Achieve Strong Isolation

a) Strict temporal partitioning

ARINC 653 uses static, table-driven major/minor-frame scheduling.Each partition receives: a deterministic, exclusive, pre-allocated time slice. No asynchronous kernel operations can preempt or delay a partition during its assigned window.

b) Strict spatial partitioning

ARINC 653 relies on:

static physical memory regions, enforced by hardware MMU/MPU, with immutable mappings during operation.

This guarantees zero cross-partition memory interference.

c) Hardware-level strong isolation

Both time and memory isolation are enforced using:

• MMU/MPU protections a minimal, static separation kernel
• no shared kernel-writable global state
• no driver execution inside the kernel
• fault containment boundaries

As a result, Misbehavior in one partition cannot contaminate others or the separation kernel, satisfying DAL A/B fault-containment requirements.

Table 1. Linux cgroups vs ARINC 653 partitions.

Table 1. Linux cgroups vs ARINC 653 partitions.

F. Abundant Linux Ecosystem

Although Linux’s extensive ecosystem is often viewed as an engineering advantage, this richness provides little benefit in a certification context. As previously discussed, Linux already lacks strong spatial and temporal isolation due to its shared monolithic kernel. Beyond these architectural issues, the scale of the Linux ecosystem introduces a second, independent barrier: the broader the ecosystem, the larger the portion of the build and integration toolchain that must be addressed under DO-330 (or DO-33*) tool-qualification requirements.

Because Linux relies on a wide array of compilers, linkers, meta-build systems, configuration generators, device-tree compilers, package utilities, and scripting frameworks, each of these components becomes part of the certification scope when used to produce airborne software. A richer ecosystem necessarily expands:

• the number of tools involved in the build pipeline,
• the number of transformations applied to source artifacts,
• the number of scripts and generators that must be controlled or assessed, and
• the number of potential interactions requiring justification or qualification under DO-330.

Eventually, ecosystem breadth directly multiplies certification effort, even before considering version churn or kernel-level complexity. In contrast, certifiable ARINC 653 platforms deliberately employ minimal, stable, and highly controlled toolchains precisely to keep DO-330 obligations tractable.

Table 2. Common misconceptions about Linux for safety-critical systems.

Table 2. Common misconceptions about Linux for safety-critical systems.

VI. Recommendations

• Partitioning Kernels / Type-1 Hypervisors: XtratuM + LithOS, POK, JetOS
• Separation Kernels + User-Space ARINC Services: seL4 (MCS), Muen SK
• Commercial Certifiable Platforms: VxWorks 653, INTEGRITY-178B, LynxOS-178, PikeOS, DeOS

VII. Conclusions

References

1. ARINC Industry Activities, ARINC Specification 653P1-3: Avionics Application Software Standard Interface, Part 1. ARINC: Annapolis, MD, USA, 2015.
2. ARINC Industry Activities, ARINC Specification 653P3-2: Avionics Application Software Standard Interface, Part 3. ARINC: Annapolis, MD, USA, 2014.
3. RTCA Inc. DO-178C: Software Considerations in Airborne Systems and Equipment Certification. RTCA: Washington, DC, USA, 2011.
4. EUROCAE, ED-12C: Software Considerations in Airborne Systems and Equipment Certification; EUROCAE: Paris, France, 2011.
5. RTCA Inc. DO-297: Integrated Modular Avionics (IMA) Design Guidance and Certification Considerations. RTCA: Washington, DC, USA, 2005.
6. RTCA Inc. DO-330: Software Tool Qualification Considerations. RTCA: Washington, DC, USA, 2011.
7. He, F.; Xiong, H.; Zhou, X. Overview of key technologies for ARINC 653 partitioned operating systems. Acta Aeronaut. Astronaut. Sin. 2014, vol. 35(no. 7), 1777–1796. [Google Scholar]
8. Huang, R. Research on ARINC 653 partition isolation mechanism for IMA. Ph.D. dissertation, Sch. Electr. Eng., Northwestern Polytech. Univ., Xi’an, China, 2020. [Google Scholar]
9. Lopez, I.; Parra, P.; Urueña, M. XtratuM: a hypervisor for partitioned embedded real-time systems. Proc. 18th Int. Conf. Real-Time Netw. Syst. (RTNS), Paris, France, 2010; pp. 1–6. [Google Scholar]
10. Delange, J.; Pautet, L.; Faucou, S. POK: an ARINC 653 compliant operating system for high-integrity systems. In Reliable Software Technologies – Ada-Europe 2010; Springer: Berlin, Germany, 2010; pp. 172–185. [Google Scholar]
11. Huber, B.; Lackorzynski, A.; Warg, A. seL4: formal verification of a high-assurance microkernel. Commun. ACM 2014, vol. 57(no. 3), 107–115. [Google Scholar]
12. Kuz, I.; Elphinstone, K.; Heiser, G. MCS: temporal isolation in the seL4 microkernel. Proc. 11th Oper. Syst. Platforms Embedded Real-Time Appl. (OSPERT), New York, NY, USA, 2015; IEEE; pp. 1–6. [Google Scholar]
13. Härtig, H.; Lackorzynski, A.; Warg, A. The Muen Separation Kernel: Design and Formal Verification; Tech. Univ. Dresden: Dresden, Germany, 2018. [Google Scholar]
14. Bovet, D.; Cesati, M. Understanding the Linux Kernel; O’Reilly Media: Sebastopol, CA, USA, 2005; pp. 1–986. [Google Scholar]
15. Gleixner, T. PREEMPT_RT Patch Overview and Design Philosophy; Linux Foundation: San Francisco, CA, USA, 2019; Available online: https://wiki.linuxfoundation.org/realtime/start (accessed on 2 March 2026).
16. Wind River Systems Inc., VxWorks 653 Platform Datasheet, 2022. Available online: https://www.windriver.com (accessed on 2 March 2026).
17. Green Hills Software Inc., INTEGRITY-178B RTOS for Avionics. 2021. Available online: https://www.ghs.com (accessed on 2 March 2026).
18. SYSGO AG. PikeOS Safety-Certifiable RTOS and Hypervisor. 2024. Available online: https://www.sysgo.com (accessed on 2 March 2026).
19. DDC-I Inc. DeOS Safety-Critical RTOS. 2024. Available online: https://www.ddci.com (accessed on 2 March 2026).

Biography