On Oct. 13, Red Hat and Berlin-based Ferrous Systems announced a collaboration to put Ferrocene, Ferrous Systems’ safety-qualified Rust toolchain, on Red Hat In-Vehicle Operating System. Ferrocene is qualified under ISO 26262 up to ASIL D, the highest automotive safety integrity level, and a subset of Rust’s core library is certified for ASIL B workloads. Ferrocene 26.05 already ships a qualified aarch64-rhivos2-linux-gnu target, so teams can start writing and testing code now. Full general availability is planned for the second half of 2027, lined up with safety-certified releases of the operating system.
The point of the deal is paperwork that every automaker would otherwise repeat. Using any compiler in a safety-critical electronic control unit means qualifying the toolchain and keeping traceable evidence, and Red Hat says pre-aligning Ferrocene with its OS cuts that cost and custom validation work. “Safety-critical development requires more than the right language. You also need a qualified toolchain and the evidence that goes with it,” said Ferrous Systems managing director Florian Gilcher. Upstreambeat notes the fine print: qualified use requires cross-compiling from the matching Red Hat Enterprise Linux 10 host on aarch64.
Three days later, Ferrous Systems released Ferrocene 26.08.0 with three newly qualified targets: Armv7-R bare metal with hard float, Armv8-A on QNX SDP 8.0 and later, and x86-64 on QNX SDP 8.0 and later. The release pulls in upstream changes from Rust 1.96.0 through 1.97.1. Ferrocene is TÜV SÜD-qualified for ISO 26262 (ASIL D), IEC 61508 (SIL 3) and IEC 62304 (Class C), which covers cars, industrial machines and medical devices with one compiler that stays drop-in compatible with the standard Rust toolchain.
That version gap matters. Upstream Rust is already at 1.99.1, which shipped on Oct. 15 to fix a miscompilation: on x86_64, Rust functions returning bool through the C interface could leave bits 1 to 7 of the return register unspecified, so C callers could see values other than 0 or 1. That is exactly the boundary Red Hat is selling, mixed Rust and C/C++ code inside one controller. A qualified toolchain trails upstream on purpose, because each version has to be tested and documented before it can be trusted with a brake or an airbag.
The certification map for Rust is filling in quickly. Last week we covered rail signaling under EN 50716 and AdaCore’s push for MC/DC coverage, the test evidence DO-178C demands for DAL A flight software, which AdaCore is now building into the open-source compiler with the Rust Foundation. For engineering buyers, the useful questions are concrete: which compiler version is qualified, for which target, to which standard, and what evidence comes with it. A gradual path, one component at a time behind a C interface, is what makes adoption realistic in a controller that already runs millions of lines of C.
N23D is written entirely in Rust, from CAD geometry to the shop floor. Its MES plan includes a Rust PID controller designed to run on minimal hardware, which is where qualified bare-metal targets like Armv7-R become directly useful. The QMS is designed to record which toolchain built each released binary, so the compiler version becomes part of the product record in PLM rather than a note in someone’s build script.
Sources
- Red Hat and Ferrous Systems Collaborate to Enable Safety-Qualified Rust on Red Hat In-Vehicle Operating System, Red Hat press release (Oct. 13, 2026)
- Red Hat gives automotive Rust a qualified path onto In-Vehicle OS, Upstreambeat (Oct. 13, 2026)
- Ferrocene 26.08.0 now available, Ferrocene blog (Oct. 16, 2026)
- Announcing Rust 1.99.1, Rust Blog (Oct. 15, 2026)
- Rust for DO-178C and ISO 26262, AdaCore blog (Oct. 5, 2026)
Featured photo: Used car airbag ECU by Daniel S. Fowler, CC BY-SA 4.0, via Wikimedia Commons.
.jpg){kind=link}