Speed is being gathered around the idea of adding rust to the Linux kernel. Why is this a big deal, and what does it mean for the rest of us? The Linux kernel has only been C and assembly for its entire lifetime. A large project like Kernel has a lot of shared tooling to work with its languages, so adding another is quite an initiative. Project culture has also developed around language choice. So why exactly are the gray-beards of kernel development entertaining the idea of even adding rust? To answer one line, because C was designed in 1971, to run on Bell Labs minicomputers. If you want to shoot yourself in the leg, C will give you the loaded firearm.
On the other hand, if you want to write a kernel, C is a great language for low-level coding. Direct memory access? Yes inline assembly? Sure. Any garbage collection or way run directly on metal, with virtual machines? Absolutely. But all the things that make CK great for kernel programming make CK dangerous for kernel programming.
Now I hear your combined keyboards panicking: “Safe C code writing is possible!” Yes, yes it is possible. It’s very easy to mess up, and when you mess up a kernel, you have security vulnerabilities. There are some things that are objective Terrible About C, such as indefinite behavior. C compilers try their best to do the right thing like cursed code i++ + i++; Or a[i] = i++;. But it’s almost certainly not going to do what you want, and even worse, it could be Sometimes Do the right thing.
Rust seems to be gaining popularity. There are some ambitious projects out there, such as Corioteal Rewriting in Rust. Many other standard applications are getting a rusty rewrite. It is quite inevitable that the collection of rust developers begin to ask, can we attack the next kernel? It was created for a Linux plumber conference, and the response to the mailing list was cautiously optimistic. If rust can be added without breaking things, and without losing things too much that makes rust useful, then yes it would be interesting.
Why rust
So what makes rust so attractive? Here are the two main answers. First, it is a modern language with a strong memory-security guarantee. (There’s a caveat here, and we’ll cover the insecure code later.) About two-thirds of all security vulnerabilities are the result of some memory handling bugs, and rust eliminates them fairly. A second bonus, rust has some nice things that we’ve come to realize in modern language, such as easy to use. STRING Type in the built-in standard library and some simple functions for common situations like string comparison.
The other answer is that rust is a simple fit with C code and kernel programming. Rust It has compiler magic. The code you write actually works without any interpreter or garbage collection effort. The rust in the object oriented pattern did not overdose, but blended nicely with the C-style struts already used in the kernel. Even the stack model is very similar to the C.
There is a problem with the Rust Memory-Safe Guarantee – it is impossible to write a kernel that is officially memory-safe. A kernel needs to be written to an indefinite memory, math weird pointers, and other seemingly bizarre things to make our computers work in reality. It does not work well with a language that tries to guarantee that memory manipulation is safe. How do you write kernel code with rust? Added rust unsafe Allows the use of keywords, direct memory access and other such techniques that do not work with Rust’s memory guarantee. Put potential problems together and it makes auditing easier.
There is at least one other language that might come to mind as an extended update of C that tries to do some of these things: C ++. Sure it would fit better, wouldn’t it? Kernel devs have some strong feelings about this idea. To put it mildly, any improvements to C ++ do not apply to the kernel context, and some other changes come in the right direction.
What’s the plan?
So can we see the kernel completely rewritten in the rust? Nothing like that. The kernel development process is strictly conservative, so the initial introduction of rust will be done in the least disobedient way possible – the driver code. Kernel as second-in-command [Greg Kroah-Hartman] Write it, “Drivers are probably the first place for such an endeavor because they are the‘ last leaf ’of the dependency tree on the kernel source. They depend on the functionality of the original kernel, but nothing depends on them. “
In practice, this means that tooling, documentation, and example code will now be integrated into the kernel. At some point in the future, one of the interested parties like Google, Rust will start writing new drivers. Google seems keen to turn parts of Android into rust, perhaps in an attempt to thwart the continued pwnage of their OS from the likes of the NSO group. Rust has a useful example driver on the Google Security blog. This is another interesting connection [Miguel Ojeda], The main developer of the Rust for the Linux effort, has now been assigned full time by Prossimo for that purpose. Prosimo is an arm of the Internet Security Research Group, also known for leading Let’s Encrypt. Funding for [Ojeda]The work was provided by Google.
So where are we now? Version 6 of the rust patch has only been sent to the kernel mailing list. Some minor changes have been requested, but most notably developers have begun calling for the patches to be dragged into the 5.19 kernel once its merge window opens. 5.18-rc6 has just been released, so in two to three weeks we will see that the kernel mint will be a final release, and the 5.19 merge window will open. That’s right, in about three weeks we’ll see Rust attached to the Linux kernel!
Once it finally lands, expect to see a generic driver that actually uses support in the following versions. So if 5.19 sees rust support, then a driver with rust written will probably happen at 5.20. As indicated above, Google is one of the parties most interested in rusting efforts for Linux. It will probably port some Android-related code to Rust, as part of Google’s ongoing efforts to improve the security of their mobile ecosystem.
What could be the possible mistakes?
Rust almost certainly happens in Linux, but is it guaranteed to be a good thing? There are several possible downsides to consider. First, the interface between C and Rust is a potential place for cropping unexpected bugs. This is new code, some of which is automated, some are working fancy – there must be surprises. This is not really a problem with any new code. The bugs are fixed, the problems are fixed.
What could be more of a problem is the additional complexity of the debugging problem when there is another language to consider. So far, the kernel has enjoyed the advantage that it is present in all C’s and all programmers working on it are familiar with that language. Add a second language, and now C programmers, rusty programmers and some who are actually proficient in both. There is another compiler that can probably initiate errors and there is another toolchain for managing.
After all, there is a danger that it will not catch up. It could be that the kernel community collectively shakes, and continues to write code in C and support Rust Bit-Rot. This is the least problematic issue, as the support of big players like Google makes it impossible and the code is easy to remove even if the vine dies on the vine.
Can any of the above issues be a breach of contract? Probably not. Adding rust will change the way kernel development develops and kernel maintainers will have to brush up on their rust knowledge. The potential benefits seem to outweigh the downsides. Torvalds seems to have adopted the rusty concept of kernel, once the last few sacrifices have been ironed. We look forward to seeing Rust mature in Linux, and we’ll bring you the rest of the story as soon as that happens.