Rust in the Linux Kernel: First Steps and Controversies

Actualizado: 2026-05-03

Since version 6.1 (December 2022), the Linux kernel officially accepts code in Rust. In 2023 we’ve seen the first real upstream drivers and the community debate over how to integrate two languages with very different philosophies. We cover where things stand, which modules use it already, and why some kernel veterans view it sceptically.

Key takeaways

• Rust enters the kernel to eliminate a class of bugs impossible to eradicate in C: memory-safety errors in new drivers.
• The strategy is conservative: existing C code isn’t rewritten; Rust is used for new modules and drivers.
• The Apple AGX GPU driver for Asahi Linux is the most prominent real-world example to date.
• The social controversy — two development cultures in the same project — is the bigger obstacle, not the technical one.
• The C/Rust infrastructure requires bindgen for bindings and an exact rustc version per kernel release.

The “Why” of the Project

The Linux kernel accumulates 30+ years of C, with everything good and bad about it: extraordinary performance, total control over memory and hardware, but also a large chunk of critical OS CVEs caused by memory-safety errors — use-after-free, buffer overflows, data races. Microsoft estimated in 2019 that ~70% of its annual vulnerabilities were of this kind. The figures in the Linux kernel are comparable.

Rust offers, without GC, memory-safety guarantees verified at compile time. The core idea: if new drivers — especially those written by people with fewer years of C — are written in Rust, an entire class of bugs disappears. Old kernel C isn’t rewritten; you just avoid adding more old-style attack surface.

2023 State: What’s in Upstream

What’s already in upstream or close to it:

• Base infrastructure: Rust bindings to core kernel structures (sk_buff, file_operations, ioctl, etc.) and the “abi” of how Rust calls C and vice versa.
• Apple AGX driver (Asahi Linux): Apple Silicon GPU, written in Rust by Asahi Lina. Keeps Linux usable on M1/M2 Macs.
• Initial NVMe driver and network-driver experiments in review.
• Ethernet PHY (some models).
• PuzzleFS filesystem: experimental, but an example of a complete Rust subsystem.

It’s a modest start compared with the vastness of the kernel, but investment from Google, Microsoft, Asahi, and other maintainers guarantees continuity.

How C/Rust Coexistence Works

Kernel Rust code compiles to a static blob the linker integrates like any other object. Cross-language calls pass through bindings layers generated by bindgen, which transform C headers into Rust types.

Important restrictions to know:

• No std: the kernel has no libc or standard allocator. A minimal variant (alloc + kernel-specific types) is used.
• Abundant unsafe in bindings: the language boundary requires breaking some Rust guarantees. The idea is to contain unsafe in small, well-reviewed modules.
• Release-specific compiler: the kernel requires an exact rustc version per release, with no tolerance for minor versions. This clashes with Rust’s “always up-to-date” model.

The result is Rust, but more restricted than in userspace. The abstractions still mature release by release.

The Social Controversy

Two communities, two cultures. The most prominent visible controversy of the year: in 2023, some C maintainers viewed the expectations of Rust developers as a culture-change demand — asking for stricter documentation of invariants in C interfaces that worked for decades “because”. This ended with resignations and bitter discussions on the kernel mailing list.

Linus Torvalds has publicly supported the project but also asked for patience from both sides.

The most reasonable arguments against (not the purely reactionary):

• Dual cognitive cost. Maintainers reviewing C and Rust code need competence in both languages.
• Heavier toolchain. Building the kernel now requires rustc in addition to gcc/clang.
• More complex debugging. Traditional tools (kgdb, ftrace) are designed for C; Rust support lags.
• 20-year maintainability. The kernel must remain buildable for decades. Betting on a relatively young language assumes longevity risk.

Arguments in favour are the obvious ones: entire classes of bugs eliminated upfront, better onboarding for new developers, more expressive type model. Compared with adjacent technologies like WebAssembly — where Rust also plays a central role — the adoption trend is clear.

What to Expect Short-term

Reasonable forecasts for the next 12-18 months:

• More new-hardware drivers written directly in Rust, especially where there are large companies behind it (GPUs, NICs).
• Experimental subsystems (filesystems, network stacks) with Rust implementations parallel to C.
• No rewriting of core parts (scheduler, MM, VFS) — cost and risk are too high.
• Continuation of the cultural debate, with gradual improvements in interface documentation.

Conclusion

Rust in the Linux kernel is already a technical reality, not an academic experiment. The next few years will decide whether the experiment scales — whether the community finds a way to integrate two cultures and two languages without collapsing under the weight of change. The bet makes sense long-term for reducing the memory-bug surface in new drivers, but the path is more social than technical.

If you want to contribute, Rust for Linux^[1] is the entry point.

1. Rust for Linux