Rust in Linux: stable drivers and first serious contributions

Actualizado: 2026-05-03

When Linus Torvalds merged the first pieces of Rust support into Linux 6.1 in October 2022, the warning was explicit: it was an experiment. Three years later we have enough material to judge without speculating. Rust drivers have started being marked as stable, the internal API has matured considerably, and some strategic subsystems have chosen Rust as the preferred language for new code. The project has left the purely exploratory phase.

Key takeaways

• The Apple ASAHI GPU driver is the loudest case: large, active and critical for a specific audience.
• The Android binder module rewritten in Rust is receiving successive merges and shapes up as the IPC mechanism going forward.
• Rust code in-tree remains below 1 % of the kernel, but growth in the last six months has been faster than in any prior window.
• At least two veteran maintainers stepped back citing Rust pressure as a factor.
• Google has demonstrated parallel drops in memory-safety CVEs as Android incorporates more Rust code.

What is stable in-tree

In Linux 6.14, several merged Rust drivers coexist, marked as functional:

• Apple ASAHI GPU driver for Apple Silicon: the only practical path to graphics acceleration on Apple ARM laptops running Linux. It is large, active and critical for a specific audience, and has been the stress test of Rust support in quality terms.
• Android binder module, rewritten in Rust, receiving successive merges in recent versions.
• Partial nvme subsystem Rust implementations under active review, with expectation of merging in 6.15 or 6.16.
• null-block support (used in benchmarking and testing) fully rewritten.

Rust code in-tree is still small in relative terms, likely under 1 % of the kernel total. But growth in the last six months has been faster than in any prior window, and the cadence of patches through the rust-for-linux list has multiplied.

Internal API maturity

One of the biggest early problems was that kernel Rust needed to map types and behaviors from the underlying C, and that mapping was unclear. A consolidated pattern set now lets you write drivers without reinventing the wheel each time:

• Abstractions for locks, DMA buffers, kernel-style linked lists, and error handling follow an idiomatic form adjusted to kernel constraints.
• The Rust standard runtime isn’t used, no alloc from the standard library, memory management is explicit.
• The build layer has stabilised: compiling the kernel with Rust support no longer requires magic.

Learning to write kernel Rust has its own curve distinct from userspace Rust, but the curve keeps shortening as good in-tree examples multiply. Those already working with OS-level profiling tools like eBPF have a useful foundation for understanding the kernel execution model.

The unresolved internal controversy

Not everyone is comfortable with the direction. Through 2024 there were at least two public exits by veteran maintainers citing Rust pressure as a reason, or at least as a factor, for stepping back. The discussion of whether Rust should be merely allowed or actively preferred for new contributions remains open.

Torvalds’s position has been consistent: Rust can coexist with C if the bridges are well-designed, and maintainers have the last word over their trees. He won’t force anyone to accept Rust code, but he won’t block it on principle when quality is good.

The underlying technical debate is legitimate. Rust adds cognitive load for C maintainers reviewing Rust code, and adds complexity to the build system. In return it offers memory safety and a clearer concurrency model. The balance depends on the subsystem: for new drivers with little legacy code, the gain is obvious; for mature code with decades of polished C, the gain is less clear.

Adoption outside mainline

Who is accelerating kernel Rust use most isn’t Linux mainline but Android. Google has invested publicly and consistently in Rust for Android since 2021, and their published vulnerability statistics are the best demonstration argument. Each new Android version has more Rust lines, and memory-safety CVEs drop in parallel.

Commercial kernel forks from Red Hat, Oracle and SUSE are tracking closely. Rust deployed at scale on enterprise servers isn’t yet observed, but that’s expected given the conservative pace of enterprise kernels.

Experimental projects also exist: Maestro (a fully Rust-written kernel), Asterinas, and academic researchers working on Rust hypervisors. None will replace Linux, but all contribute ideas that eventually filter back into rust-for-linux. Some of these Rust hypervisors compete conceptually with Firecracker in the microVM space.

What remains unresolved

Three important pieces are still open:

1. Integration with static analysis tools Linux uses to validate C code, like sparse or Coccinelle. Adapting them to Rust is non-trivial.
2. Multi-architecture support. Rust compiles well for x86_64 and arm64, covering most deployments, but PowerPC, RISC-V and several embedded architectures have partial or experimental Rust support.
3. Training. Few developers have simultaneous Rust and Linux kernel experience. Without a broad contributor base, kernel Rust risks depending on a few key names.

My read

The experiment has stopped being an experiment. Rust in the Linux kernel is a production technology with real drivers, sustained merge cadence, and downstream adoption in projects like Android where security metrics are measurable. It isn’t dominating the kernel and won’t in the coming years, but neither is it a curiosity.

What I find notable is how it is forcing debates the C ecosystem could postpone indefinitely: explicit ownership, formalised concurrency models, compiler-verifiable safety guarantees. These debates benefit even parts of the code that remain pure C.

For anyone who values Rust as a language, this is a good time to explore rust-for-linux. Docs are clear, there are starter-labelled issues, and the project needs hands. The direction has been consistent for three years, and security data supports the original thesis.