Rust in Linux: Experimental Drivers Opening the Way
Actualizado: 2026-05-03
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 versus ongoing direction debate. This article covers the real state and what it means for OS security.
Key takeaways
- 70 % of kernel vulnerabilities are memory safety bugs; Rust eliminates them at compile time.
- 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, core 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 different projects:
- 70 % of kernel vulnerabilities are memory safety bugs: use-after-free, buffer overflows, data races.
- 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:
- 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[1] — 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[2] 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 kernel internals — 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: memory safety bugs represent 60–70 % of kernel CVEs. Reduction potential is massive.
- 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.
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 — 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.
