This article is more than 1 year old

Keep calm and learn Rust: We'll be seeing a lot more of the language in Linux very soon

It's another string to your bow

Opinion To become a Linux developer, you used to need C as your passport. Now Rust can let you be an OS programmer as well.

The joke goes: "C combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language." Having programmed in both C and IBM 360 Assembler – it was a long time ago, OK – there's something to that. Because of its power, performance, and portability, C became the operating system language of choice, including, of course, Linux.

There's only one little problem with C. It's really easy to make blunders. Big, ugly ones. That's where Rust comes in.

You see, according to Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit, almost two-thirds of Linux kernel security holes [PDF] come from memory safety issues. And where do they originate? Inherent weaknesses in C and C++. Rust, on the other hand, dodges these issues by using far safer application programming interfaces (APIs). Specifically, Rust advocates claim the language won't let you leak memory or create potential buffer overflows.

People complaining about 'Rustification' in userspace isn't a great sign for any future kernel use, but hey, we'll see – Linus Torvalds

That sounds good to me. Better still, it sounds good to kernel developers. At the 2020 Linux Plumbers Conference, programmers suggested it was time to consider using the Rust language for new Linux inline code [PDF] since Rust is "a better C in the way the kernel wants C to be."

Don't think for a moment that they're proposing to rewrite 25 million lines of C in Rust. They're not that crazy! They just want the option of using Rust for new Linux code.

Of course, that comes with its own problems. Rust must make use of the existing Linux kernel APIs; deal with the application binary interface (ABI) compatibility between Rust and C; and developers and maintainers will have to deal with two languages rather than just one.

The million-line-code question is: "What does Linus Torvalds think?" Because if he doesn't like it, it's not going anywhere.

Even though he cut his teeth on C, Torvalds is open to using Rust in Linux. But, as he wrote in the Linux Kernel Mailing List (LKML) in July 2020, he's cautious. "I'd want the first rust driver (or whatever) to be introduced in such a simple format that failures will be obvious and simple."

Since then, Torvalds has become a trifle more welcoming. In an interview, Torvalds tells me that while he's "in no way 'pushing' for Rust," he's "open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."

Torvalds says: "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one."

Besides, since "lots of drivers are only relevant on a couple of target architectures, the whole issue with Rust code not being supported on some architectures is less of an issue."

Senior Linux kernel developer Greg Kroah-Hartman tells me he agrees that "drivers are probably the first place for an attempt like this as they are the 'end leaves' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."

Just because Torvalds and Kroah-Hartman are open to Rust doesn't mean everyone is. Torvalds adds: "People complaining about 'Rustification' in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects – more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called 'C'), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)."

Still, Kroah-Hartman says: "It will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."

So the door is open, but who gets to bell the cat of actually doing the code? First up is Sylvestre Ledru, daytime Mozilla director and night-time Debian Linux developer. He has ported a Rust version of Coreutils, the basic GNU file, shell, and text manipulation utilities, to Linux using the LLVM compiler infrastructure and its Clang C language front end. Ledru has ported it to Debian Linux. You can currently boot Linux with it and get the GNOME desktop up and running, install many of the most popular Debian packages, and to build Firefox, the Linux kernel, and LLVM/Clang on it. Mind you, it's not production-ready, some commands are much slower than their C ancestors and others don't support all the options, but it's a good start.

Google is funding the Internet Security Research Group (ISRG), best known for Let's Encrypt, to sponsor Rust in Linux. This isn't the first time ISRG has turned its hand to fixing memory problems. It has a whole department, Prossimo, devoted to memory-safe programming. Its other projects are a memory-safe TLS module for the Apache web server, a memory-safe curl data transfer utility, and memory-safe Rustls – a safer OpenSSL alternative.

These funds will be used to pay Miguel Ojeda, a software engineer and Linux kernel developer, to work full-time on Rust in Linux. Earlier, Ojeda had created a Request for Comment (RFC) on the matter. This lays out concerns over bringing "a new main language in the kernel" and the rewards that might come from using Rust in Linux. These are:

  • New code written in Rust has a reduced risk of memory safety bugs, data races, and logic bugs overall.
  • Maintainers are more confident in refactoring and accepting patches for modules thanks to the safe subset of Rust.
  • New drivers and modules become easier to write, thanks to abstractions that are easier to reason about, based on modern language features, as well as backed by detailed documentation.
  • More people get involved overall in developing the kernel thanks to the usage of a modern language.
  • By taking advantage of Rust tooling, we keep enforcing the documentation guidelines we have established so far in the project. For instance, we require having all public APIs, safety preconditions, "unsafe" blocks, and type invariants documented.

So how is it going so far? At the 2021 virtual Linux Plumbers Conference, Ojeda said Rust largely eliminates C code's undefined behaviour problems because "Rust doesn't have undefined behaviour." This makes it safer.

While it's perfectly OK to do safety-critical software (such as that used in a plane or a car) in C or in many languages, Rust is safe(r) in the sense that it doesn't have undefined behaviour lapses. At the same time, Ojeda insisted, if you program with Rust well, you "can generate code as good and fast as C or C++."

But for all the advantages Rust can bring to Linux, it's not without its problems. For example, "learning a second language is going to be a major burden to maintainers." The answer to that will be to provide "strict in-line documentation of the code."

Progress is being made. While you're not going to be running a Rust-based Linux kernel anytime soon – or more likely ever – you will be using Linux with many drivers and other components written in Rust soon. Some of you already are. For example, you can run AWS Bottlerocket, a largely Rust-based minimal Linux distribution for containers, today.

Stay tuned and learn Rust – good things are going for this combination. By this time next year, I expect there will be significant portions of Linux running Rust. ®

More about


Send us news

Other stories you might like