The Linux Kernel Maintainers Summit in Tokyo in December 2025 changed the status of Rust. This decision removed the experimental label from the language. Linus Torvalds stated at the 2025 Linux Foundation Open Source Summit Korea that Rust is a part of the kernel. The decision follows the initial merger of Rust infrastructure in kernel 6.1 in December 2022. While C code makes up 34 million lines of the kernel, the 25,000 lines of Rust code grew through the inclusion of drivers. The shift from experimental to core status follows five years of development since Torvalds first raised the idea in 2020. There was zero pushback against this reclassification at the summit according to kernel maintainer Steven Rostedt.
The transition followed a long timeline of technical and social negotiations. Miguel Ojeda submitted the first pull request for the Rust for Linux project on September 20, 2021. This pull request included Kbuild integration and initial support for built-in modules. The project received financial support from the Internet Security Research Group and Google. This support helped address the compile-time issues that exist in the Rust ecosystem. The development moved from the initial infrastructure in version 6.1 to core abstractions like drivers and memory allocators in versions 6.2 through 6.5. By kernel 6.6, the project included the Apple GPU driver and the Android Binder rewrite.
Security requirements drive the transition
Memory safety vulnerabilities account for 70% to 80% of Linux kernel CVEs. These vulnerabilities include buffer overflows, use-after-free bugs, and race conditions. Rust prevents these error classes through its type system and borrow checker. The National Security Agency and CISA published guidance in 2022 and 2023 that recommends memory-safe languages for systems programming. These agencies cited kernel vulnerabilities as the primary threat vector for critical infrastructure. A single kernel vulnerability can compromise an entire system because kernel exploits bypass sandboxes, container isolation, and application-level security.
The Android security team reported that zero memory safety vulnerabilities exist in Rust Android code since they began adoption. This stands in contrast to the hundreds of vulnerabilities found annually in C and C++ code within the same codebase. The effectiveness of Rust in preventing these bugs is a primary reason for its adoption. The language enforces memory safety at compile time, which removes the need for manual tracking of pointer lifetimes. This capability addresses the fundamental security weaknesses that C cannot solve.
Production implementations in the kernel
Rust code is no longer theoretical in the Linux kernel because it ships in production environments. The Android Binder IPC driver uses a Rust implementation. The Apple GPU driver, also known as the asahi-gpu driver, is written entirely in Rust. This driver implements the full Apple Silicon GPU command queue, memory management, and DMA interfaces. The implementation of the asahi driver proves that Rust can handle the most complex kernel subsystems. NVMe infrastructure also includes significant Rust contributions.
The stability of the Rust kernel API has improved as the project matured. The kernel_crate provides the necessary abstractions for driver authors to work without rewriting code for every release. The rust_out_of_tree abstraction layer helps to decouple driver code from the lowest-level kernel bindings. In the 6.13 kernel released in January 2025, developers gained access to in-place modules, bindings, and trace events. Greg Kroah-Hartman stated that Rust support reached a tipping point with these new bindings. The next stage of development includes PCI and platform drivers to enable almost all driver subsystems to accept Rust code.
Resistance from kernel maintainers
The integration of Rust into the kernel caused intense conflict between different developer groups. Christoph Hellwig, a senior Linux kernel developer, opposed a patch for Direct Memory Access (DMA) API transfers. Hellwig argued that maintaining multi-language projects is a pain and he had no interest in dealing with the impedance mismatch between Rust and C. He told Miguel Ojeda to keep the wrappers in the driver code rather than spreading the complexity to core subsystems. He described the addition of other languages to core subsystems as a way to spread cancer.
This disagreement led to a public dispute between maintainers. Hector Martin, the lead developer for Asahi Linux, criticized the kernel development process on social media. He called for Linus Torvalds to provide an authoritative answer to resolve the driver mess. When Torvalds did not intervene, Martin dropped out of the Apple/ARM platform development. Torvalds responded by telling Martin that the problem was his own attitude and that the current process works despite its problems. Danilo Krummrich, an engineer from Red Hat, tried to mediate by offering to maintain the Rust abstraction layer as a separate component, but Hellwig rejected this proposal as well.
Technical constraints of the no_std environment
Writing kernel code in Rust requires a departure from standard userspace practices. Rust kernel code operates in a no_std environment. This means that the code does not use the Rust standard library. Instead, the code uses a custom kernel_crate that provides its own allocators, synchronization primitives, and collection types. Many common patterns like std::sync::Mutex, Vec::new(), and thread::spawn do not exist or behave differently in kernel space. The kernel_crate‘s Mutex is different from the standard library version because it enforces kernel-specific rules. For example, the Mutex cannot be held while in an interrupt context.
The build process for Rust kernel modules requires specific tooling. The build system uses LLVM and libclang to understand the C code in the kernel. The bindings to the C side of the kernel are generated at build time using the bindgen tool. Developers must also ensure that the toolchain is compatible with the kernel configuration. The combination of deep kernel knowledge and Rust proficiency allows specialized engineers to command significant salary premiums at major cloud providers and semiconductor companies throughout the United States. You, as a systems engineer, likely understand that a language’s utility depends entirely on its application to the specific workload.
| Metric | Value |
|---|---|
| Linux Kernel C Code Lines | 34,000,000 |
| Linux Kernel Rust Code Lines | 25,000 |
| US Average Rust Salary | $145,447 |
| US 90th Percentile Salary | $239,003 |
| US Senior Salary Range | $156,000 – $234,000 |
| US Entry-level Salary Range | $78,000 – $104,000 |
| US Startup Average Salary | $130,292 |
| Organization Rust Use (2025) | 48.8% |
| Organization Rust Use (2023) | 38.7% |
Economic drivers and the talent market
The demand for Rust expertise has created a specialized job market. Job postings for Rust increased by 35% in 2025 according to iMocha data. Because the supply of senior Rust engineers is low, many enterprises retrain their existing C++ and Python engineers. This retraining strategy helps companies manage the steep learning curve of the language. Rust developer salaries in the US average $145,447 according to Glassdoor. Senior roles at cloud and semiconductor companies reach up to $250,000 in the US.
The investment in Rust is supported by major corporations and foundations. Google funds the salary for Miguel Ojeda, the overseer of the Rust for Linux project. The Linux Foundation also commits resources to the project. Organizations like AWS, Microsoft, and Meta use Rust in their production environments. This corporate backing provides stability to the project despite the technical challenges. Will the increasing number of Rust drivers eventually force a reconsideration of the build system requirements for all kernel contributors?
Syntax complexity and developer sentiment
The syntax of Rust remains a point of contention for developers. A 2025 survey from The Rust Blog found that 41.6% of respondents cited language complexity as a concern. Other developers complain about the noisy syntax, which includes many curly braces, semicolons, and angle brackets. Some engineers find the strongly typed APIs difficult to work with in real-world projects. One example of a complex type is the return type for the get_or_create_inode function: Result<Either<ARef<INode<T>>, inode::New<T>>>.
This complexity stems from the need to express precise ownership and lifetime information. C developers often find the transition difficult because they are used to the simpler, more permissive nature of C. The borrow checker requires developers to satisfy strict rules regarding how data is accessed and modified. While this prevents memory errors, it can slow down development velocity. Slow compilation times also remain a persistent complaint across four survey cycles.
The role of reference drivers
Maintainers use Rust reference drivers to integrate the language without disrupting the existing C codebase. A reference driver is a driver that a subsystem maintainer can introduce to their subsystem without violating the rule against duplicate drivers. This allows maintainers to bootstrap new abstractions for future drivers. It also provides a way to test the effort required for a specific subsystem. Reference drivers serve as live documentation for C maintainers to see how Rust code should look.
The use of reference drivers allows for a gradual transition. A subsystem can allow temporary breakage in Rust code to facilitate adoption. This policy prevents the burden of Rust from falling on maintainers who are focused on urgent C fixes. The strategy mimics how real-time Linux was integrated into the mainline kernel over twenty years. Rust is not a replacement for C, but an opt-in addition that targets security-sensitive drivers and subsystems.
