Rust is here to stay: the experimental phase in the Linux Kernel has ended

Key points:
  • Consensus at the Maintainers Summit in Tokyo: Rust is officially integrated and the "experimental" label is removed.
  • Mass deployment: Android 16 (Kernel 6.12) uses the ashmem memory subsystem written in Rust.
  • Future of graphics: DRM maintainer plans to ban C for new drivers within a year.
  • Security debate: Rust mitigates 15.9% of historical vulnerabilities, endorsed by Greg Kroah-Hartman.

RustLinux

The Linux kernel development community has made a final decision: Rust is here to stay. After years of testing, heated debates, and parallel development, the recent Maintainers Summit held in Tokyo, Japan, has marked the end of the evaluation stage.

At this exclusive invitation-only event, where the project's main leaders and maintainers gathered, a consensus was reached that Rust support within the kernel should no longer be considered "experimental," but an integral and permanent part of the world's most important open-source operating system.

To formalize this change of status, Miguel Ojeda, head of the Rust-for-Linux project, has sent a formal patch which removes warnings about the experimental nature of the language from the official kernel documentation. Ojeda confirmed that, after a long period of experimentation designed to assess whether the technical, procedural, and social trade-offs were worthwhile, the conclusion is clear:

"The experiment is over, meaning Rust stays."

Android 16 and the reality in production

Although the change of label in the documentation is an important formality, The technical reality is that Rust is already operating in critical production environments.Ojeda revealed a piece of information during the summit: the devices that will run Android 16, based on the Linux kernel 6.12, They will be sent with the memory allocator Ashmen (the anonymous shared memory subsystem) completely rewritten in Rust.

This implies that, far from being a proof of concept in laboratories, there is millions of consumer devices which already rely on Rust code within the kernel to function. Although Ojeda cautioned that "this doesn't mean everything will work for every kernel configuration, architecture, or toolchain," and He acknowledged that there is still much work to be done.The deployment on Android validates the stability of the language in the real world.

Furthermore, the abstraction ecosystem has matured rapidly, enabling the development of complex controllers. Currently, high-profile projects rely on this infrastructure:

  • Graphics Drivers (GPU): Nova (for NVIDIA hardware), Asahi (for Apple Silicon) and Tyr (for ARM Mali).
  • File Systems: The rust_ext2 driver.
  • IPC: A native implementation of the Binder mechanism, fundamental to the Android architecture.

The end of C for new graphics drivers: A paradigm shift

One of the most forceful statements at the summit came from Dave Airlie, responsible for the maintenance of the DRM subsystem (Direct Rendering Manager), a key piece of the Linux graphics stack. Airlie stated that the DRM project is approximately one year away from requiring Rust. and prohibit the use of C for new controllers.

This radical stance It underscores the confidence that maintainers of critical subsystems are placing in the languageGreg Kroah-Hartman, a maintainer of the stable kernel, supported this view during the discussion, stating that drivers written in Rust are proving to be objectively safer than their C counterparts. Surprisingly, Kroah-Hartman noted that the technical problems arising from the interaction between the new Rust code and the existing C kernel have been far less than initially feared.

Safety vs. Performance: The eternal debate

The central argument for this massive shift is undoubtedly memory security. According to data from the Comprehensive Vulnerabilities Dictionary (CVE), approximately 15,9% of kernel security vulnerabilities over the past 20 years are related to issues that Rust addresses by design, such as buffer overflows and use-after-free access. Companies like AWS and security experts argue that Rust eliminates entire classes of logical errors, allowing reviewers to focus on the architecture rather than manually hunting for memory leaks.

However, this view is not universal and faces resistance from the "old guard" and concerns about performance:

Brian Kernighan's Criticism: Computer science legend Brian Kernighan, co-author of the book "The C Programming Language," recently expressed his skepticism after trying the language. Kernighan described his experience with Rust as "painful," criticizing the immense complexity of the ecosystem, the slow compilation times, and the difficulty in understanding memory safety mechanisms in programs where memory management wasn't even a critical issue. For many veterans, the learning curve and the complexity of the compiler are difficult barriers to justify.

The way forward: GCCRS and Debian

To consolidate adoption, lThe community is working to eliminate the exclusive dependence on the LLVM/Clang compiler. A key project is gccrs, an implementation of Rust on GCC (the GNU Compiler Collection).

The ultimate goal is to ensure that it's always possible to compile the kernel with the Rust version included in the latest stable release of Debian. In fact, the Debian project has already stated that it will incorporate "strict Rust requirements" into its APT package manager starting in May 2026, which will force system administrators and developers to have the necessary Rust version. toolchain Rust ready in your building environments.

Despite the remaining challenges (such as support for low-usage architectures (IBM s390) and the lack of a complete formal language specification) the industry seems to have responded.


Add as preferred source