Is Linux Kernel Development Good Enough to Make Your Life Depend on It?

### Overview This talk addresses whether the mainline Linux kernel can be qualified for use in safety-critical systems, particularly autonomous driving platforms. Motivated by work at BMW Car IT and the collaborative OSADL SIL2LinuxMP project, the presentation explores methods and procedures to qualify Linux on multi-core embedded platforms according to the IEC 61508 Edition 2 standard at Safety Integrity Level 2 (SIL2). The consortium—including BMW Car IT, Intel, OSADL, Renesas, KUKA, Sensor-Technik Wiedemann, and academic/certification experts—aims to demonstrate that safety qualification of pre-existing, complex open-source software is feasible without creating a separate, private safety fork of Linux.

### Key Topics - **Functional Safety & Standards**: Defined as risk management ensuring systems operate correctly despite operator error, hardware faults, or environmental changes. Achieving SIL2 under IEC 61508 requires demonstrating freedom from unacceptable risk through rigorous quality assurance and system decomposition. - **Architectural Approaches**: Comparing methods to isolate safety software from non-safety software, including off-the-shelf hardware with simple external safety checkers, hypervisor-based virtualization, and direct OS-level isolation using Linux (relying on CPU shielding, dedicated cores, and memory partitioning via tools like the PALLOC patch). - **Handling Pre-existing Software**: Because Linux is developed without awareness of a specific vehicle or system context, safety qualifications cannot be generic. Analysis must be split into system-specific impact assessments and general process quality assessments of kernel development.

### Technical Details & Methodologies - **Hazard-Driven Decomposition, Design, and Development (HD3)**: A top-down iterative method replacing vague high-level requirements (e.g., 'the open syscall must work correctly') with precise constraints. By unrolling design levels and repeating hazard analysis, the project narrowed down 12 specific technical safety constraints for system calls like `open`. - **Assurance-Driven Selection**: Prioritizing components not just by feature completeness, but by the availability of qualification artifacts and evidence. For example, rather than trying to qualify complex general-purpose init systems like systemd, teams might qualify a simple custom program or select libraries like glibc where assurance data is abundant. - **Kernel Analysis Tools & Statistical Models**: - Statistical bug prediction models analyzing Git history (such as bug age histograms showing peaks near 500 days with long tails past 1,000–1,500 days) to estimate declining remaining defects in LTS releases. - Syscall execution trace databases evaluating independence across protection layers, path coverage, and call diversity. - Patch Impact Tester tools to check if specific patches touch an active kernel configuration. - Code minimization tools preprocessing `#ifdef` constructs to ease review and external static analysis. - **Continuous Maintenance & Backport Monitoring**: Managing the ~90 bugs fixed weekly in Linux. A two-tier review process splits responsibilities: a shared kernel analysis team assesses the generic userspace impact of upstream bug fixes, while system-specific teams evaluate whether individual fixes affect active safety functions in shipping products.

### Takeaways The central conclusion is that 'safety-critical Linux' is identical to mainline LTS Linux; the distinction lies strictly in system architecture, constrained usage, and rigorous qualification evidence. Internal forks degrade quality because company teams cannot match the broader community's review velocity and competence. Upstream collaboration, disciplined backport tracking, and assurance-driven architecture make qualifying Linux for safety-critical systems achievable within an estimated 5- to 10-year product horizon.