Why Rust is coming to the Linux kernel

Rust is already inside the Linux kernel and growing. The kernel now contains roughly 25,000 lines of Rust, mostly bindings rather than core functionality, but real features are starting to appear. The most visible example is a Rust-written QR code generator that displays crash information in the latest kernel release. The broader story is that Rust is being introduced not as a replacement for C, but as a safer way to write new code—especially drivers—while the existing 40 million lines of C remain in place.

Why Rust is being adopted now

• The Perinux developers spent years preparing Rust support and asked kernel leadership if they wanted it; the response was to try the experiment.
• Government mandates are pushing against memory-unsafe languages like C in products, creating external pressure to adopt safer alternatives.
• Rust’s ownership and lifetime model eliminates a large class of common kernel bugs: off-by-one array overwrites, forgotten error-path cleanup, missed unlocks, and incorrect reference counting when devices are hot-removed.
• Google’s recent data showed that writing new code in Rust, while leaving old C code alone, led to overwhelmingly more secure software because most bugs appear in new code, not old code.

What “memory safety” in Rust actually means here

• It does not mean the kernel can never crash. Rust’s safety is about object lifetimes and ownership: when something goes out of scope, it gets cleaned up properly, and the compiler enforces rules about who owns what memory.
• Logic bugs are still possible, and Rust code can still be memory-unsafe if it ignores buffer sizes or uses unsafe blocks. The QR code Rust code itself once scribbled over memory because it forgot to check the buffer size passed from C.
• Greg estimates that about half of the kernel bugs he has seen over the past 18 years would be prevented by Rust, but it is not a silver bullet.

The hard part: meshing Rust with the existing C kernel

• Writing a core kernel subsystem in Rust would actually be easier than writing a driver, because drivers must interact with many kernel subsystems: locking, I/O, the driver model, USB, and so on.
• Each of those interactions requires a binding layer between C and Rust, because the kernel’s C code has very opinionated models for objects and memory, and Rust has its own very opinionated models. Making them talk to each other is complex and produces some of the most difficult Rust code in existence.
• Over the past couple of years, developers have been steadily writing these bindings, and the infrastructure is now at a point where real drivers can be written.

Rust is also improving the C code

• Writing bindings forces kernel developers to document and clean up their C code so Rust can use it safely.
• Greg gave a personal example: he initially thought the Rust binding for the driver core was horrible and unworkable. After meeting with the Rust developers at a Rust Linux conference, he realized both sides were wrong. The Rust side had written a thousand lines of Rust to avoid changing two lines of C. Once they agreed to change the C code, the Rust side shrank dramatically.
• This pattern—Rust exposing unclear assumptions in C and prompting safer, simpler C code—is happening across the kernel, even though some core kernel developers resist the change and prefer a single-language project.

Where Rust is likely to show up first

• Simple hardware drivers that mostly read and write memory-mapped registers are a natural fit, and can actually be written in less code in Rust than in C.
• Red Hat developers are beginning to write new Nvidia GPU drivers in Rust and are submitting proposals.
• Apple GPU drivers for MacBooks have been written in Rust and are running on a fork, though not yet merged. Graphics drivers have complex object-lifetime issues that Rust makes easier to handle.
• The general expectation is that new drivers and new code will increasingly be written in Rust, while the existing C codebase is protected with other safety measures.

The C code is not going away, and is being hardened in parallel

• The kernel team is working with compiler authors to add bounds checking, “seat belts and airbags,” and new C extensions to make existing C code safer.
• The strategy is not to rewrite 40 million lines of C in Rust, but to write new code in Rust and make the old C code less dangerous.
• Greg’s stance is pragmatic: if Rust fails, it can be removed, but there are developers willing to do the work, it is not intruding on other people’s code, and the project needs to evolve to survive.