Since version 6.1 (December 2022), the Linux kernel officially accepts code in Rust. In 2023 we’ve seen the first real drivers in upstream and the community debate over how to integrate two languages with very different philosophies. Here we cover where we stand, which modules use it already, and why some kernel veterans view it sceptically.
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 this kind. Similar numbers in kernel.
Rust offers, without GC, memory-safety guarantees verified at compile time. The 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.
State in 2023
What’s already in upstream or close to it:
- Infrastructure: Rust bindings to core kernel structures (sk_buff, file_operations, ioctl, etc.). 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).
- PuzzleFS filesystem: experimental, but an example of a complete Rust subsystem.
It’s a modest start compared with the vastness of the kernel, but the direction is set and 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:
- No
std: the kernel has no libc or standard allocator. A minimal variant (alloc+ kernel-specific types) is used. - Abundant
unsafein bindings: the language boundary requires breaking some Rust guarantees. The idea is to containunsafein small, well-reviewed modules. - Specific compiler: the kernel requires an exact
rustcversion 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 see 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 practical reality: integrating two communities of developers with different styles in the same project takes more diplomacy than engineering.
The most reasonable arguments against (not the purely reactionary):
- Dual cognitive cost. Maintainers reviewing C and Rust code need competence in both.
- Heavier toolchain. Building the kernel now requires
rustcin addition togcc/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 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.
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, but the path is more social than technical.
If you want to contribute, Rust for Linux is the entry point. Follow us on jacar.es for more on base-technology evolution.
