Cover image for Safety-Critical Linux: What Certifying It Actually Takes

Raghu Bharadwaj

Safety-critical Linux means running Linux where a failure can injure someone: in cars, industrial robots, and medical devices. You cannot certify the whole kernel the way a small safety controller is certified, so the industry does something different. It certifies a defined Linux configuration as a Safety Element out of Context, with documented assumptions about how it is used, wraps it in a small high-integrity monitor and hardware partitioning so a fault cannot spread, and keeps that certification current as the code changes. For embedded engineers this creates a durable new skill set built around safety architecture, not just kernel code.

For most of its history, Linux was kept out of the part of a product that can hurt people. It ran the dashboard, not the brakes; the hospital display, not the infusion pump's dosing loop. That line is now moving. Software-defined vehicles, surgical robots, and industrial automation want one capable operating system across the whole device, and increasingly that operating system is Linux. Safety-critical Linux is the effort to let Linux take those roles without lowering the safety bar. This article explains why it is hard, how it is actually being done, and what the shift means for embedded and kernel engineers.

Why safety-critical Linux is suddenly real

The clearest evidence is a certificate. Through 2024 and 2025, Red Hat's In-Vehicle Operating System, built on Red Hat Enterprise Linux, earned staged functional safety certification against ISO 26262:2018 at ASIL-B from the certification body exida, reaching general availability in 2025. Functional safety standards define graded integrity levels: ISO 26262 in automotive runs from ASIL-A to the most stringent ASIL-D, IEC 62304 governs medical device software, DO-178C covers airborne systems, and IEC 61508 is the industrial base standard. A general-purpose Linux distribution carrying any automotive ASIL rating at all would have sounded unlikely a few years ago.

Behind that milestone is a community effort. The Linux Foundation's ELISA project, short for Enabling Linux In Safety Applications, brings together automotive, semiconductor, and industrial members to define shared tools and processes for building and certifying Linux-based safety-critical systems, and to work directly with certification authorities and standards bodies.

💡 Key insight: The question has shifted from "can Linux be safe?" to "for which defined configuration, in which context, and with what monitoring can we make a safety argument?" That reframing is what made recent certifications possible.

Why you cannot certify Linux the classic way

Traditional safety certification assumes a development process that Linux never followed. A classic safety component is built to a requirements-driven V-model: every requirement is written down, traced to design, traced to code, and traced to a test, often with structural coverage such as MC/DC. That is workable for a few tens of thousands of lines written for one purpose. The Linux kernel is tens of millions of lines, contributed by thousands of people, changing every week, and it was never written against a complete, traceable requirements set. There is also no guarantee, by construction, that one misbehaving component cannot corrupt another.

So you cannot simply run the whole kernel through a V-model audit and emit a certificate. The realistic path for safety-critical Linux is to change what you are certifying and how you argue for it.

💡 Key insight: Safety is not security. Security asks whether an attacker can break in; safety asks whether the system reaches a safe state when something fails, including plain hardware faults and its own bugs. A system can be hardened and still be unsafe, and the standards, evidence, and skills are different.

How it is actually done

Safety-critical Linux is achieved by combining several techniques, and none of them is "prove the whole kernel correct."

Safety Element out of Context (SEooC). Rather than certify Linux in general, a vendor certifies a specific configuration for an assumed context and writes down the Assumptions of Use that must hold. Red Hat's certification follows exactly this route: it is an SEooC for ASIL-B on a predefined set of target hardware, using ISO 26262 part 6 as an assessment framework and aligning with ISO/PAS 8926:2024, a specification for gaining confidence in pre-existing software. The integrator is then responsible for honouring those assumptions.

A safety monitor carries the integrity. Instead of trusting the large Linux-based function, the design adds a small, simple, high-integrity component that checks the result and forces a safe state if something is wrong. Because that monitor is small, it can be developed and certified the classic way, and the heavy integrity requirement moves off Linux and onto it. This is the mixed-criticality pattern, often with a real-time OS handling the critical loop on one core while Linux runs the rich functions on another.

Freedom from interference. The safety and non-safety parts must be kept from corrupting each other's memory, timing, and execution. That is enforced with hardware and partitioning: separate cores, a memory protection or management unit, or a hypervisor such as Xen, whose safety work is an active topic inside ELISA.

Continuous certification. Because Linux keeps changing, the certification cannot be a one-time event. The evidence and arguments are maintained as the codebase moves, which is why vendors describe their offering as continuously certified rather than certified once.

What ELISA is building

ELISA's contribution is the shared groundwork that no single company wants to rebuild alone. Its working groups cover automotive, medical devices, aerospace, and cross-cutting systems and engineering-process concerns, and they produce open tools and documentation: ways to describe kernel configurations, to trace requirements to tests, to reason about which kernel features and subsystems a safety argument depends on, and to record the engineering process itself. Recent community work spans the safety analysis of the Xen hypervisor and open-source quality management systems for medical software. The project is expanding, with new industrial and academic members joining through 2026.

What this means for embedded and kernel engineers

Safety-critical Linux creates demand for a skill set that sits between kernel engineering and safety engineering, and very few people currently hold both. The valuable abilities are concrete: designing freedom from interference with partitioning and hypervisors; architecting a safety monitor so the integrity requirement lands on a small component rather than the whole system; disciplined kernel configuration and requirements traceability so a build is reproducible and auditable; understanding ASIL decomposition and Assumptions of Use; and running mixed-criticality designs where an RTOS and Linux share one SoC. Knowing the kernel is the baseline; knowing how to make a defensible safety argument around it is the scarce part. For engineers willing to learn both, this is one of the more durable specialisations the next decade will reward.

Key takeaways

  • Safety-critical Linux is now real in production: Red Hat's In-Vehicle OS reached ISO 26262 ASIL-B in 2025, certified as a Safety Element out of Context by exida.
  • You cannot certify the whole kernel by the classic requirements-driven V-model; it is too large, too fluid, and was never written to that process.
  • The workable path is a defined configuration plus Assumptions of Use, a small safety monitor that carries the integrity, freedom from interference through partitioning, and continuous certification.
  • Safety is a different discipline from security, with different standards (ISO 26262, IEC 62304, DO-178C, IEC 61508) and different evidence.
  • The emerging, scarce skill set is safety architecture around Linux, not just Linux internals.

Frequently asked questions

Can the Linux kernel itself be certified to ISO 26262?
Not as a whole in the classic sense. What gets certified is a specific configuration for a defined context, as a Safety Element out of Context with documented Assumptions of Use, supported by monitoring and partitioning around it. Red Hat's In-Vehicle OS was certified this way at ASIL-B.

Is safety-critical Linux the same as a secure or hardened Linux?
No. Security is about resisting attackers; safety is about reaching a safe state when something fails, including hardware faults and software bugs. They use different standards and different evidence, and a hardened system can still be unsafe.

What is a safety monitor and why does it matter?
It is a small, simple, high-integrity component that checks the Linux-based function and forces a safe state on failure. Because it is small it can be certified the classic way, which moves the heavy integrity requirement off the large Linux system.

What is ELISA?
The Linux Foundation's Enabling Linux In Safety Applications project. Its members build shared tools and processes for creating and certifying Linux-based safety-critical systems and work with certification and standards bodies across automotive, medical, and aerospace domains.

Further reading

Originally published on TECH VEDA.