Rust: Officially Released in Linux 6.1 Kernel
At the weekend, Linus Torvalds hit the button, releasing Linux 6.1 to the world. Among other security features is support for writing parts of the kernel in Rust.
Last month, the NSA pleaded with devs to switch to memory-safe languages—such as Rust. The reason: Most security vulnerabilities are caused by bugs in memory usage.
Linux’s initial focus is to write new device drivers in Rust. In today’s SB Blogwatch, we love to oxidize.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Disney voice actors.
Linus Counts to 6.1
What’s the craic? Jonathan Corbet lists some security-related changes—“The 6.1 kernel is out”:
Linus has released the 6.1 kernel; he is preparing for a tricky holiday merge window. … Headline features in 6.1 include:
- Reworked, LLVM-based control-flow integrity,
- Initial support for kernel development in Rust, …
- The kernel memory sanitizer,
- And much more.
Ah, yes, Rust. How’s that going? Steven J. Vaughan-Nichols has big news—“Rusty release could be a game-changer”:
“Shoved down kernel developers’ throats”
With 6.1 … there is something fundamentally different. For the first time in Linux’s history, in addition to C, you’ll be able to use another language, Rust, for kernel development. … And, that, my friends, is big news indeed.
…
Almost two-thirds of … security holes 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). Rust is simply safer than C. … This isn’t just a theory. It works. Google, for example, is now using Rust extensively in Android.
…
Rust is being slowly and steadily introduced into the kernel. There are no quick changes being shoved down kernel developers’ throats.
Why is it safer? ELI5. GrayShade explains like I’m 25:
Understand the divide between what a C program is allowed to do and the guarantees the Rust compiler gives you. C doesn’t even have the language to describe those guarantees. … Take some basic C function: … char * frob(char *, char *, int, int);
…
You might have some ideas about what this function might do. It looks like it takes two pointers and two lengths, so they look like buffers, however:
There’s nothing in the code to actually guarantee that,
You might not even have the code (it’s probably from some ancient library),
You don’t know if any or either of the pointers can be NULL,
You don’t know if these are bytes or characters, and if embedded 0s will have a special meaning or not,
You don’t know, in principle, which buffer has which length,
You don’t even know if they are actually buffers, as the code might cast the pointers to something else,
Lengths are normally size_t, who knows why these are int?
There’s no const there. This might be intentional, or just old code, or a programmer who doesn’t trust in language restrictions,
But you don’t know what the function reads and where it writes. … C and C++ don’t have the vocabulary to answer these. The compiler doesn’t know the answers. The debug info doesn’t have the answers. … C and C++, and every static analyzer I’ve seen, don’t even have the terms to describe a temporal relationship between pointers or references. … In Rust you have to describe these complex relationships.
Why focus on drivers? phantomfive doesn’t mince words:
The driver code is a good candidate for Rust, because driver code is often low quality, and the drivers are well-encapsulated. So using Rust means that whole classes of bugs won’t show up as a result of incompetent coding, in what tends to be the most incompetently written part of the kernel.
But who are these Rust people, anyway? Nick Cameron raises concerns:
First, and absolutely most importantly, we (the Rust project) need to sort out our governance and leadership issues. This blocks so much potential work and the longer it goes on, the more ‘governance debt’ the project accrues and the more problems will build up down the line. It is embarrassing that a year after the core team imploded there still isn’t even a proposal for a new leadership team.
…
There is a ton more work in Rust governance that I think needs to be done, primarily updating the RFC process and revisiting the team and working group structure. But this is blocked on having a leadership team and completing the current changes.
Wait. Pause. “Imploded”? Say it ain’t so! u/Yaahallo says it ain’t so:
The core team became increasingly isolated over time as the project grew. As a result they had an increasingly hard time making their work legible to the rest of the project which caused trust breakdowns. This spiraled from there and resulted in interpersonal conflicts and further communication breakdowns until everything exploded.
…
The core of the problem is that the project has historically taken a reactive stance to policy and governance. We create systems when things are broken and make them work as long as we can. … What we need to start doing is proactively reviewing how things are going and give each other feedback on the systems and policies we have in place and iterate on them much more often. … Active feedback plus some more robust connections and communication lines between teams, particularly at the most general levels of the project, will go a long way and would almost certainly have addressed the problems that caused the governance meltdown.
But why a whole new language? Can’t we just fix C and its toolchain? bachchain says no:
Sure it’s nice to fantasize about theoreticals, but here in reality, what matters are the things that can actually exist. The fact of the matter is that the C family has spent billions of dollars and millions of man-hours over the past fifty years trying to “fix it with tooling,” yet we’re nowhere near close.
…
It’s never going to happen.
Meanwhile, heed a puntastic The Evil Atheist:
Most Rust development will be used for drivers. For the kernel proper, they’re adopting a wait-and-C approach.
And Finally:
Something for my animation nerd friends
Hat tip: Ambegris
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: The Linux Foundation (cc:by-nc; leveled and cropped)
