Rust in Linux: Experimental Drivers Opening the Way

Rust in the Linux kernel moved from “interesting idea” to operational reality during 2022-2024. Linux 6.1 (Dec 2022) merged initial support. Linux 6.9 (May 2024) brings significant advances: merged experimental drivers, community frameworks, and first real Rust-in-kernel cases vs ongoing direction debate. This article covers the real state in mid-2024.

Context

The problem Rust addresses:

70% of kernel vulnerabilities are memory-safety bugs (use-after-free, buffer overflow, data races).
C makes preventing these hard at code review.
Rust’s ownership model eliminates these bug classes at compile time.

For a kernel like Linux with tens of millions of lines, introducing memory-safe language is strategic.

Linux 6.9 State

Merged components:

Rust abstractions layer: kernel API bindings (memory, sync, io).
Sample drivers: hello world, echo.
Infrastructure: crate management, testing framework.

Experimental drivers merging:

Partial NVMe driver in Rust: demonstrative POC.
Apple Silicon GPU driver (Asahi): written in Rust, notable.
drivers/net/phy: some PHY drivers.

No critical mainline modules written only in Rust yet. Focus is abstractions + experimental drivers.

Apple Silicon GPU: The Star Driver

Asahi Linux (Apple Silicon Linux support) wrote its entire GPU driver in Rust. It’s:

Real driver, not POC.
Running on thousands of machines.
Performance comparable to native C drivers.
Successful proof of concept for the approach.

Asahi showed Rust in kernel works for real drivers.

Why Rust vs C

Concrete advantages:

Compile-time memory safety: use-after-free, data races impossible by construction.
Explicit error handling: Result<T,E> vs forgettable return codes.
Zero-cost abstractions: performance equal to C.
Ownership: clear who frees what.
Modern tooling: cargo equivalent, rustfmt, clippy.

Disadvantages in kernel context:

Steep curve for C kernel devs.
Slower compile time than C.
Crate ecosystem vs kernel subset.
Change churn: Rust evolves fast, kernel wants stability.

The Debate

Tensions in Linux community:

Pro-Rust

Linus Torvalds approved inclusion, but cautiously.
Many devs see memory safety as long-term necessary.
Companies (Google, Microsoft) have invested.
New drivers lean Rust-first in some projects.

Anti-Rust / Cautious

Some maintainers (Greg Kroah-Hartman, several subsystem ones) have reservations.
Dual-API complexity: each subsystem now has C API + Rust bindings.
Fragmentation: code review harder with two languages.
Backwards compatibility: Rust bindings break with kernel changes.

2024 drama: some maintainers refused to review Rust code for their subsystem, arguing they won’t maintain Rust bindings.

Path Forward

(Tentative) consensus:

Rust is additional, not C replacement.
New drivers can choose Rust if maintainer OK.
Core kernel stays C for now.
Gradual evolution: no big-bang conversion.

Who Contributes

Google (Android team): Binder driver in Rust.
Microsoft: Azure Linux, HyperV drivers under evaluation.
Red Hat: investing in Rust abstractions.
Amazon: some interest.
Asahi community: real traction.

Corporate + community diversity = sustainability.

How to Start

For kernel devs wanting to experiment:

Read Rust for Linux docs.
Compile kernel with Rust enabled: kernel 6.1+ + rustc.
Sample drivers in samples/rust/.
Write experimental driver: toy project.
Contribute abstractions to rust-for-linux tree.

Real learning curve but feasible if you know Rust and kernel basics.

Conceptual Alternatives

Other kernel memory-safety approaches:

RedoxOS: complete OS in Rust from scratch. Hobby but playground.
Google Fuchsia: microkernel in C++ with Rust components.
BSD kernels: still C, but moving slowly.
seL4: formally-verified microkernel.

Linux + Rust is pragmatic middle — keeps huge ecosystem and adds safety incrementally.

Security Impact

If half the kernel were in Rust in 5-10 years:

CVE reduction: memory-safety bugs represent 60-70% of kernel CVEs. Massive potential reduction.
Supply chain: third-party drivers with stronger guarantees.
Development velocity: safer refactoring.

Doesn’t solve everything (logic bugs, complex concurrency, hardware issues) but is massive win.

Cases Where Rust-in-Kernel Clearly Wins

New drivers with state complexity.
Critical security: crypto, networking security.
Embedded systems: where kernel footprint matters.

Cases where C remains better:

Simple drivers for old hardware.
Mature stable subsystems.
Micro-optimised performance (rare edge cases).

The Future

Pragmatic predictions for coming years:

2024-2025: more experimental drivers, abstractions stabilising.
2026-2027: first serious Rust drivers in mainline (non-experimental).
2028+: consideration for new subsystems.
2030+: possible significant Rust in core kernel.

Slow but steady timeline. Linux kernel doesn’t rewrite fast.

Conclusion

Rust in Linux is now reality, not promise. Experimental drivers run in production (Asahi Silicon). Debate over adoption pace continues — maintainers with legitimate complexity reservations. But direction is clear: memory-safe language arrived at the kernel to stay. For systems programmers learning Rust, there’s real opportunity to contribute and shape the future. For enterprises dependent on Linux, it’s a trend to follow. The C-only kernel era is closing slowly but unequivocally.