iTranslated by AI

The content below is an AI-generated translation. This is an experimental feature, and may contain errors. View original article
🐧

Rust Graduates from Experimental Status in the Linux Kernel

に公開

Introduction

The talk about Rust being introduced into the Linux kernel has been around for several years.
However, recently, a clear agreement has been reached among kernel maintainers that Rust support has "ended its experimental status and is now intended for long-term use."

I believe this is highly significant, not just as a language trend, but because
language selection has begun to change in the most conservative of domains: the OS kernel.

Why did the Linux kernel accept Rust?

The primary reason is memory safety.

Many of the vulnerabilities reported in the Linux kernel are

  • use-after-free
  • buffer overflow
  • null pointer dereference

which are classes of bugs that are difficult to prevent in C.

Rust is designed to "structurally prevent such bugs from being written" by checking ownership, borrowing, and lifetimes at compile time.

As a result, it has been valued in the Linux kernel for its ability to:

  • reduce accidents before the review stage
  • fundamentally lower the burden on maintainers

What it means that the "experimental" label was removed

The important point is that Rust is not meant to replace C.

The current policy is as follows:

  • Maintain existing C code
  • Adopt Rust for new code, especially device drivers
  • Premised on the coexistence of C and Rust

This agreement is akin to a message stating:
"Rust is not a pilot program, but a language that will continue to be used."

Some maintainers have even made statements to the effect that
"Rust is recommended for new drivers."

Where is it actually being used?

At present, the primary areas where Rust is being used are:

  • Device drivers
  • Linux kernel-related code for Android
  • Components loosely coupled with other subsystems

The reasons are clear:

  • Boundaries are well-defined
  • It is easy to localize unsafe blocks
  • The interface with C is limited

There are no current plans to rewrite the entire Linux kernel in Rust.
A realistic approach of "using Rust in high-risk areas first" seems to be being adopted.

Vulnerabilities still occur in Rust

It is a common misconception, but
Rust does not mean absolute safety.

In fact, vulnerabilities have been reported even in Rust code within the Linux kernel due to:

  • Misuse of unsafe blocks
  • Flaws in concurrency design
  • Logic bugs

However, Rust has the following characteristics:

  • Issues are concentrated in unsafe blocks
  • The types of bugs are limited
  • The targets for review become clear

The essence of Rust is not that "bugs become zero," but rather that
"the way bugs occur can be controlled."

What will happen to Rust engineers?

This trend is highly significant.

  • Rust is no longer an application-only language.
  • Demand for Rust in OS, drivers, and infrastructure software will increase.
  • It is becoming a "next-generation standard candidate" rather than a simple replacement for C.

Especially for engineers working in embedded or low-level layers, Rust is becoming a technology that will be unavoidable in the future.

Conclusion

The formal acceptance of Rust by the Linux kernel is not about

  • The outcome of a language war
  • A temporary trend

but rather, I believe it demonstrates

"the limits of a design that relies on human attention for safety."

Rust is not a panacea.
However, a massive project like Linux has begun to show that it is a language particularly suited for high-risk areas.

In the coming years,
the question of "where to use Rust"
will become increasingly practical.

Discussion