It’s been over two years since Rust was officially merged into the Linux kernel with version 6.1, and the journey has been anything but smooth. This week, the Rust for Linux project hit another milestone with expanded driver support landing in the 6.13 development cycle, and it’s a good moment to take stock of where things stand.
I’ve been writing C for the better part of three decades. I understand the kernel community’s attachment to the language — it’s not just familiarity, it’s a deeply optimized toolchain and decades of institutional knowledge. But watching the Rust integration unfold has been one of the most interesting language adoption stories I’ve seen in my career.
The Technical Progress#
The numbers tell a compelling story. Rust code in the kernel has grown from the initial infrastructure patches to real, functional subsystems. The Android team at Google has been the most visible driver, with Rust-based Binder IPC drivers in active development. The network PHY driver abstractions have been another success story, demonstrating that Rust can interface cleanly with existing C subsystems through well-designed safe abstractions.
The key technical insight that makes Rust work in the kernel is the concept of safe abstractions over unsafe primitives. The low-level hardware interactions still happen in unsafe blocks — you can’t avoid that when talking directly to hardware registers — but the API exposed to driver authors is safe Rust. A driver author working with a well-designed abstraction layer doesn’t need to think about use-after-free or data races. The compiler catches those classes of bugs at build time.
This matters because driver code is where most kernel bugs live. Studies consistently show that around 70% of kernel vulnerabilities are memory safety issues. If Rust can meaningfully reduce that number in new driver code, the security impact is significant.
The Cultural Friction#
The technical challenges are solvable. The cultural ones are harder. The kernel community’s mailing list has seen heated debates about Rust, ranging from legitimate technical concerns to more fundamental disagreements about the direction of the project.
Some veteran maintainers have pushed back on the idea that their C subsystems should need to accommodate Rust bindings. The argument isn’t unreasonable: maintaining bindings between two languages adds complexity, and the C side shouldn’t be constrained by what Rust can or can’t express. But the counterargument — that new contributors are increasingly more comfortable with Rust than C, and that memory safety provides measurable security benefits — is equally valid.
Linus Torvalds has been pragmatic about it, as he tends to be. His position has essentially been: Rust needs to prove itself on its merits, maintainers shouldn’t be forced to learn it, and the integration should be gradual. That’s a reasonable stance, and it’s more or less what’s happening.
What I’m Watching#
The most interesting development isn’t the technical integration — it’s the tooling story. The Rust compiler’s target support for kernel builds has improved significantly, but there are still pain points around build system integration, cross-compilation for unusual architectures, and debugging tooling.
GDB and LLDB support for mixed C/Rust debugging in kernel context is still rough. When you’re debugging a kernel panic that crosses the C-Rust boundary, the experience is nowhere near as smooth as pure C debugging with established tools. This is the kind of practical friction that determines whether working kernel developers actually adopt a language, regardless of its theoretical benefits.
The alloc crate situation is another area to watch. The kernel can’t use Rust’s standard allocation mechanisms because kernel memory allocation is fundamentally different — it needs to handle allocation failures gracefully, support different memory types (DMA, MMIO, etc.), and work within specific context constraints. The Rust for Linux project has built custom allocator support, but this means kernel Rust code can’t easily reuse libraries from the broader Rust ecosystem. It’s a necessary trade-off, but it limits one of Rust’s biggest advantages: its package ecosystem.
The Broader Implications#
What’s happening in the Linux kernel is a microcosm of a larger trend. Safety-critical systems everywhere are grappling with the same question: can we adopt languages with stronger safety guarantees without abandoning decades of existing code and expertise?
The White House’s report on memory-safe languages from early 2024 put a policy spotlight on this question, and the ripple effects are reaching into defense contracting, automotive, and medical device software. Linux’s approach — gradual adoption, interoperability with C, safe abstractions over unsafe foundations — is likely the template that other large C codebases will follow.
My Take#
I think Rust in the kernel will succeed, but it will take another five years before it’s unremarkable. The driver ecosystem is where the impact will be felt first — new hardware drivers written in Rust, old ones maintained in C. The idea that the kernel will ever be fully rewritten in Rust is fantasy, and nobody serious is proposing it.
What I find most valuable isn’t the language itself but the conversation it’s forcing. Every time a Rust abstraction needs to encode a kernel invariant in the type system, it makes that invariant explicit. Even if you never write a line of Rust, the process of defining safe interfaces improves understanding of the existing C code.
For those of us building systems on top of the kernel, the practical impact is still minimal. But if you’re writing kernel modules or embedded drivers, learning Rust’s ownership model is a worthwhile investment. The direction is clear, even if the timeline isn’t.
More on language and ecosystem evolution in my Developer Landscape series.