In late 2022, Linus Torvalds merged Rust support into the Linux kernel. It was controversial — kernel developers had spent decades perfecting C discipline, and adding a new language created real concerns about complexity, toolchain requirements, and whether Rust’s safety guarantees actually held in the kernel’s memory model.
Three years later, we have real data. Rust is in production kernel code, major contributors are writing new subsystems in it, and the momentum has shifted from “interesting experiment” to “this is happening.”
What’s Actually in the Kernel in Rust
The Linux kernel now contains Rust code in several places:
Drivers: This was always the intended entry point. Apple’s kernel drivers for their silicon have Rust contributions. Google has contributed Android-specific drivers. Nova, a Rust-based open-source driver for NVIDIA GPUs, is in development and generating significant attention.
The rust/ directory: Contains the Rust core infrastructure — the kernel crate, abstractions over kernel APIs, and the build system integration. This is what driver authors use.
Filesystem experiments: The NVMe subsystem has seen Rust contributions. There are exploratory Rust filesystem implementations.
Net filter: Some networking subsystem work has Rust components.
The vast majority of the kernel remains C — and will for decades. Rust in the kernel is about new code, not rewriting existing code.
Why Rust in the Kernel Matters: Memory Safety
Linux kernel bugs are disproportionately memory safety issues — use-after-free, buffer overflows, integer overflows, null pointer dereferences. Research consistently shows that 60-70% of CVEs in system software are memory safety issues:
- CVE-2022-0847 (Dirty Pipe): Use-after-free
- CVE-2021-4154: Use-after-free in kernel memory
- CVE-2023-6931: Heap buffer overflow in performance monitoring
Rust eliminates entire classes of these bugs at compile time. The borrow checker enforces that:
- References cannot outlive their owners (no use-after-free)
- You can’t have mutable and immutable references simultaneously (no data races)
- Buffer access is bounds-checked by default (no buffer overflows without
unsafe)
A Rust kernel driver that compiles correctly cannot have a use-after-free bug — not because the programmer was careful, but because the compiler rejected it.
Writing a Simple Linux Kernel Module in Rust
// A minimal Linux kernel module in Rust
// drivers/my_driver/src/lib.rs
use kernel::prelude::*;
use kernel::module;
module! {
type: MyModule,
name: "my_driver",
author: "BordenCastle",
description: "A simple Rust kernel module",
license: "GPL",
}
struct MyModule {
_pin: PhantomPinned,
}
impl kernel::Module for MyModule {
fn init(_module: &'static ThisModule) -> Result<Self> {
pr_info!("Rust module loaded!\n");
Ok(MyModule {
_pin: PhantomPinned,
})
}
}
impl Drop for MyModule {
fn drop(&mut self) {
pr_info!("Rust module unloaded!\n");
}
}
This is much simpler than equivalent C kernel code. The module! macro handles registration, Drop handles cleanup, and Rust’s type system handles resource management — you literally can’t forget to free memory.
The unsafe Reality
Rust in the kernel is not purely safe Rust. Interacting with the kernel’s C infrastructure, hardware registers, and DMA buffers requires unsafe:
// Example: unsafe is required for raw hardware access
unsafe fn read_device_register(base: *const u32, offset: usize) -> u32 {
// Safety: base is a valid device MMIO address, offset is within bounds
core::ptr::read_volatile(base.add(offset))
}
The key difference from C: in Rust, unsafe is explicit and localized. When you see unsafe, you know exactly where to focus review. In C, any line of code could have memory safety issues — there’s no syntactic signal.
The Linux kernel’s Rust abstractions are designed to minimize the unsafe surface area that individual drivers need to use. If the abstraction layer handles the unsafe correctly, driver code can be entirely safe Rust.
Google’s Investment: Android and Chrome OS
Google is the largest contributor to Rust in the Linux kernel, driven primarily by Android. Android’s kernel runs on billions of devices, and any kernel vulnerability is a critical security issue.
Google’s approach:
- New Android kernel drivers are required to be written in Rust (when possible)
- High-risk existing drivers are candidates for Rust rewrites
- The Android kernel Rust infrastructure is contributed upstream to mainline Linux
Results reported by Google: Zero memory safety bugs in production from the Rust Android driver code deployed so far. The comparison to equivalent C drivers that had memory safety CVEs is the compelling argument.
The Developer Experience Challenge
Writing kernel Rust is harder than writing userspace Rust:
No standard library: The kernel can’t use std. You get core and alloc, and the kernel provides its own kernel crate with abstractions.
Stable Rust requirement: The kernel requires a specific minimum Rust version and uses some unstable features carefully. This creates toolchain management overhead.
Learning curve: You need to understand both Rust and kernel programming. There aren’t many people who know both well yet.
Documentation gaps: The kernel’s Rust documentation is improving but still lags the C documentation significantly.
The toolchain setup for kernel development:
# Install specific Rust version for kernel development
rustup toolchain install nightly-2024-11-01 # Check kernel requirements
rustup component add rust-src --toolchain nightly-2024-11-01
rustup component add rustfmt clippy
# Build a kernel module with Rust support
make LLVM=1 rustavailable # Check if Rust is available
make LLVM=1 menuconfig # Enable CONFIG_RUST in kernel config
make LLVM=1 -j$(nproc) # Build with LLVM (required for Rust)
What This Means for Security
The long-term security implications are significant:
Reducing CVE surface: If new driver code can’t have use-after-free bugs by construction, the CVE rate for new code drops. This takes years to manifest as the percentage of Rust code grows.
Raising the bar for attackers: Even in C code, the existence of Rust tooling and patterns in the kernel improves code review practices and provides better abstractions that C drivers can use.
Government and regulatory pressure: The NSA, CISA, and EU cybersecurity bodies have all published guidance recommending memory-safe languages for systems code. The Linux kernel moving toward Rust aligns with these pressures and may affect government Linux adoption requirements.
Controversies and Criticisms
It’s not all positive. Longstanding kernel developers have raised legitimate concerns:
- Toolchain complexity: Requiring LLVM and a specific Rust version adds dependencies that complicate distribution packaging
- Code review burden: C developers reviewing Rust code (and vice versa) increases review friction
- Maintenance longevity: C has 50 years of tooling stability. Rust is young — will the kernel’s Rust code be maintainable in 2040?
- Abstraction cost: Some Rust abstractions over kernel APIs add overhead or restrict what’s expressible
These are real concerns, not FUD. The kernel community is navigating them, but it’s not a settled debate.
Conclusion
Rust in the Linux kernel is no longer an experiment — it’s a fact of life that will shape how kernel code is written for decades. The memory safety argument is compelling, the Google investment is significant, and the momentum is real.
For security-focused infrastructure operators, this is good news in the long term: new kernel code will have demonstrably fewer memory safety vulnerabilities. For developers interested in systems programming, Rust kernel development is one of the most interesting areas in computing right now. The tooling is maturing, the community is growing, and the problems being solved are genuinely hard.
The kernel won’t be rewritten in Rust. But the Rust code that gets written will be safer — and that matters.
