Debating Linux in Aerospace: Objections and Paths Forward
summary
Argues that using Linux requires concrete artifacts: demonstrate compliance with DO-178C (and DO-330–DO-333) for Aviation, map requirements to code for Design Assurance Level A–E (statement, branch, and full decision-combination coverage), and supply evidence via reverse-engineered certification artifacts. Practical paths include shipping only a curated baseline (git-managed build recipes and configs), moving risky drivers to user space or guests under a hypervisor (CAST-32A / AMC 20-193 guidance), and applying automated static and dynamic scanners plus documented impact analysis.
AI-written summary · about
chapters (4)
- 0:00Start
- 13:39Possible path forward •Reverse engineer artifacts from source code, forward engineer from system requirements, weave together for a complete set that satisfies all objectives • Create an appropriate coding standard, apply to code, patch problems • Identify architecture, encourage community adherence -Perform a safety analysis to look for possible fla
- 17:22Possible path forward • Curated and baselined profiles with defined configuration .Configuration should include both the compiler config (for builds) and the overall system config for which drivers are
- 18:41The design of Linux does not permit safety ⚫ Kernel is monolithic ⚫Drivers all run at kernel level with highest privilege
related talks
44mPanel Discussion: Enabling Linux in Safety Applications
57mA Development Environment for DO-178C Level D Certified Linux
41mEmbedded Linux in Space!
42mEnabling Linux in Safety-Critical Applications
47mBoldly Going, Running Linux in Space
16mTuning Linux for Embedded Space Applications
16mKeynote: Space Grade Linux: Building a Safer, Open Source Future for Space Systems
40mBuilding Safe Systems with Linux