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. ®

Similar topics


Other stories you might like

  • GPL legal battle: Vizio told by judge it will have to answer breach-of-contract claims
    Fine-print crucially deemed contractual agreement as well as copyright license in smartTV source-code case

    The Software Freedom Conservancy (SFC) has won a significant legal victory in its ongoing effort to force Vizio to publish the source code of its SmartCast TV software, which is said to contain GPLv2 and LGPLv2.1 copyleft-licensed components.

    SFC sued Vizio, claiming it was in breach of contract by failing to obey the terms of the GPLv2 and LGPLv2.1 licenses that require source code to be made public when certain conditions are met, and sought declaratory relief on behalf of Vizio TV owners. SFC wanted its breach-of-contract arguments to be heard by the Orange County Superior Court in California, though Vizio kicked the matter up to the district court level in central California where it hoped to avoid the contract issue and defend its corner using just federal copyright law.

    On Friday, Federal District Judge Josephine Staton sided with SFC and granted its motion to send its lawsuit back to superior court. To do so, Judge Staton had to decide whether or not the federal Copyright Act preempted the SFC's breach-of-contract allegations; in the end, she decided it didn't.

    Continue reading
  • US brings first-of-its-kind criminal charges of Bitcoin-based sanctions-busting
    Citizen allegedly moved $10m-plus in BTC into banned nation

    US prosecutors have accused an American citizen of illegally funneling more than $10 million in Bitcoin into an economically sanctioned country.

    It's said the resulting criminal charges of sanctions busting through the use of cryptocurrency are the first of their kind to be brought in the US.

    Under the United States' International Emergency Economic Powers Act (IEEA), it is illegal for a citizen or institution within the US to transfer funds, directly or indirectly, to a sanctioned country, such as Iran, Cuba, North Korea, or Russia. If there is evidence the IEEA was willfully violated, a criminal case should follow. If an individual or financial exchange was unwittingly involved in evading sanctions, they may be subject to civil action. 

    Continue reading
  • Meta hires network chip guru from Intel: What does this mean for future silicon?
    Why be a customer when you can develop your own custom semiconductors

    Analysis Here's something that should raise eyebrows in the datacenter world: Facebook parent company Meta has hired a veteran networking chip engineer from Intel to lead silicon design efforts in the internet giant's infrastructure hardware engineering group.

    Jon Dama started as director of silicon in May for Meta's infrastructure hardware group, a role that has him "responsible for several design teams innovating the datacenter for scale," according to his LinkedIn profile. In a blurb, Dama indicated that a team is already in place at Meta, and he hopes to "scale the next several doublings of data processing" with them.

    Though we couldn't confirm it, we think it's likely that Dama is reporting to Alexis Bjorlin, Meta's vice president of infrastructure hardware who previously worked with Dama when she was general manager of Intel's Connectivity group before serving a two-year stint at Broadcom.

    Continue reading

Biting the hand that feeds IT © 1998–2022