Rust in Linux: Experimental Drivers Opening the Way
Updated: 2026-07-07
Rust in the Linux kernel moved from "interesting idea" to operational reality during 2022-2024. Linux 6.1 (December 2022) merged initial support. Linux 6.9 (May 2024) brought significant advances: merged experimental drivers, community frameworks, and the first real Rust-in-kernel cases, alongside an ongoing direction debate. This article covers the real state in 6.9 and what it means for OS security.
Key takeaways
-
In large-scale C/C++ projects such as Chromium, around 70 % of serious security bugs are memory bugs; Rust eliminates that class of bug at compile time, which is the pattern driving its entry into the kernel.
-
The Asahi Linux GPU driver (Apple Silicon), written entirely in Rust, proves the approach works in real production.
-
Rust is additional, not a C replacement: the consensus is "new drivers can choose Rust, the core of the kernel stays in C."
-
The main friction is not technical but organisational: some maintainers refuse to review or maintain Rust bindings.
-
For systems programmers learning Rust, there is a real opportunity to contribute now.
The problem Rust addresses
The statistics are consistent across large C/C++ codebases: Chromium reports that around 70 % of its serious security bugs are memory bugs[1] (use-after-free, buffer overflows, data races), and the same pattern shows up in comparable codebases.
-
Most of those bugs are use-after-free, buffer overflows, and data races: memory-management errors, not business-logic errors.
-
C makes preventing these bugs hard: code review can detect them but not systematically eliminate them.
-
Rust’s ownership model makes these bug classes impossible at compile time.
For a kernel with tens of millions of lines of code and thousands of contributors, introducing a memory-safe language is a long-term strategic decision, not an aesthetic preference.
State in Linux 6.9
Components merged into the main tree (documented in the official kernel Rust docs[2]):
-
Rust abstractions layer: kernel API bindings (memory, synchronisation, I/O).
-
Sample drivers: hello world and echo examples.
-
Infrastructure: crate management, testing framework.
Experimental drivers merged or in progress:
-
Partial NVMe driver in Rust: demonstrative POC.
-
Apple Silicon GPU driver (Asahi): written in Rust, already in production.
-
drivers/net/phy: some PHY drivers.
No critical mainline modules written only in Rust yet. Focus is on the abstractions layer and experimental drivers.
The Asahi driver: a successful proof of concept
Asahi Linux[3], the project bringing Linux to Apple Silicon, wrote its entire GPU driver in Rust. This is:
-
A real driver, not an academic POC.
-
Running on thousands of Apple M1/M2 machines.
-
With performance comparable to native C drivers.
-
The most convincing demonstration that Rust in the kernel works.
Asahi chose Rust for a complex driver with significant state (GPU management, commands, memory synchronisation), precisely where C tends to produce the subtlest bugs.
Why Rust versus C in the kernel
Concrete advantages:
-
Compile-time memory safety: use-after-free and data races are impossible by construction, not by discipline.
-
Explicit error handling:
Result<T,E>instead of return codes that get forgotten. -
Zero-cost abstractions: same performance as C, with more guarantees.
-
Clear ownership: who frees what is encoded in the types.
-
Modern tooling:
rustfmt,clippy, cargo equivalent.
Disadvantages in kernel context:
-
High learning curve for C-accustomed developers.
-
Slower compile time than C.
-
Crate ecosystem different from the subset the kernel needs.
-
Change churn: Rust evolves fast; the kernel wants API stability.
The community debate
Tensions are real and public:
In favour of Rust:
-
Linus Torvalds approved inclusion, though cautiously.
-
Google (Android team), Microsoft (Azure Linux) and Red Hat are investing.
-
New drivers in some projects default to Rust.
With reservations:
-
Some subsystem maintainers refuse to review Rust code for their areas.
-
Dual complexity (C API + Rust bindings) increases maintenance burden.
-
Rust bindings break with internal kernel changes more easily than C code.
The 2024 drama: some subsystem maintainers publicly declared they will not maintain corresponding Rust bindings, requiring Rust contributors to assume that responsibility.
Tentative consensus
The community position, though not formally written:
-
Rust is additional, not a C replacement.
-
New drivers can choose Rust if the subsystem maintainer agrees.
-
Core kernel (scheduler, MM, critical FS) stays in C for now.
-
Gradual evolution, no big-bang conversion.
How to start contributing
For developers wanting to experiment with Rust in the kernel:
-
Read the Rust for Linux[4] documentation.
-
Compile a kernel 6.1+ with Rust support enabled.
-
Explore sample drivers in
samples/rust/of the kernel tree. -
Write a toy driver for simple hardware.
-
Contribute abstractions to the rust-for-linux tree.
The learning curve is real: it requires knowing both Rust and the kernel’s internal workings, but it is the most concrete opportunity the kernel has offered new contributors in years.
Projected security impact
If half the new kernel code were in Rust in 5-10 years:
-
CVE reduction: if the kernel follows a pattern similar to other large-scale C/C++ projects (recall Chromium’s ~70 %), the potential reduction in memory bugs is considerable.
-
Stronger supply chain: third-party drivers with stronger security guarantees.
-
Safer refactoring: structural changes are verified by the compiler.
Does not solve logic bugs, complex concurrency, or hardware issues, but it is a significant structural improvement.
Conceptual alternatives
Other approaches to memory safety in operating systems:
-
RedoxOS: a complete operating system written in Rust from scratch. A hobbyist project useful as a testbed.
-
Google Fuchsia: a microkernel with components in Rust.
-
seL4: a formally verified microkernel written in C, without Rust.
Linux + Rust is the pragmatic path: it keeps the existing, massive ecosystem and adds memory safety incrementally.
Conclusion
Rust in Linux is now reality, not promise. The Asahi driver proves the approach works for complex production drivers. The debate over adoption pace will continue, and maintainers with reservations have legitimate concerns about added complexity, but the direction is unambiguous. For systems programmers learning Rust, there is a real opportunity to shape how the kernel evolves. For enterprises depending on Linux, it is a trend to follow: the C-only kernel era is closing, slowly but decisively.
