Although we don’t expect to see a full implementation of the Linux kernel in Rust anytime soon, this early work on integrating Rust code into the kernel’s C infrastructure is likely to be very important.
Both Microsoft and the Linux community agree that two-thirds or more of security vulnerabilities stem from memory-safety issues. As software complexity continues to increase, making it safer to write in the first place will become more and more important.
Torvalds’ pragmatism is one of the key reasons for Linux’ success, and I have no doubt his position and opinions on Rust in the Linux kernel will turn out to be the right ones.
Thom Holwerda,
Honestly I think it could be better to purpose-build a fortified OS from scratch without roping in legacy C and without having to compromise the design in order to have backwards compatibility. I get the feeling that even Linus himself knows that Linux’s legacy bloat holds back change. But I’m also aware that a brand new replacement has virtually no chance of actually happening regardless of merit. Linux’s largest assets over other competing FOSS operating systems these days is widespread support, drivers, mindshare with critical mass, software, etc – things that nobody including myself want to throw away. Users have repeatedly shown a preference to incremental changes to patch up what they have and they’re not keen on starting over, which is understandable. At the same time though it keeps us rooted to very old decisions made decades ago, which isn’t necessarily our best course forward.
A whole bunch of parts of Firefox have been replaced fairly quickly to Rust and those are core parts. If Mozilla can do it maybe Linux kernel can do it too ?
Clearly fuzzing and Valgrind, etc. alone isn’t good enough. And my guess is we won’t be running Fuchsia OS kernel (written in C++ which possibly could be safer than C, depending on how you use it) on super computers anytime soon.
The most important part is the part that talks to external systems. And in a lot of cases in the Linux kernel those are not the core parts. For example they are now starting with device drivers. Which is the biggest part of the code base. And also possibly easiest part to begin. Obviously they aren’t going to rewrite all the drivers in one go, but the goal is to have a way to see how best to integrate Rust in the kernel and build process, etc.
Lennie,
Maybe, I guess there’s room for reserved optimism, haha.
Linux seems far more complicated than firefox to me. I agree with you that the drivers are by far and large where the buik of the work is at. The mountain of drivers is extremely difficult to replace in large part because nobody has the hardware under one roof. Any meaningful transition would require huge buy in from all sides and even users may have to take part in the QA effort. Alternatively, it doesn’t have to be a full adoption, rust can interface perfectly with existing C function APIs using it’s “unsafe” modifier, but IMHO going forward using C interfaces falls short of what rust is capable of. Because of the shear scale of the job, it’s likely we follow a hybrid model with some functions written in rust, but a continued dependence on C interfaces for some time.
This backwards compatibility approach seems to be the obvious pragmatic solution, but in emphasizing backwards compatibility we might miss some opportunities to develop better interfaces because we need to be compatible with the existing C code base.
Oh it’s definitely not intended to move all drivers over to Rust in the short to medium term.
It’s just that drivers are ‘leaves’ in the code tree. They only interface to one other part (set of API functions) of the code. It’s just the best place to start.
It’s obviously gonna take a while to figure out how best to handle those interfaces.
Well, one way could be to also implement part of the glibc in Rust ? So then the kernel syscall API could be changed ?? Probably not. As their are also other libc libraries.
The Chromium team too.
There’s industry wide consensus. These types of errors have remained a huge & consequential problem since the beginning of our industry. Yet we continue to use these unsafe languages for mission critical applications.
This is what needs to happen::
1) We need wide scale training at universities to increase candidate discipline in safe languages and code verification.
2) We need companies to seriously demand such skills, and apply them to new projects.
3) We need to let go of old languages and code.
Of course every one of these things is easier said than done. There’s a chicken and egg problem with universities, who won’t necessarily make academic changes prior to companies demanding it. Many companies are very resistant to change and of course we’ve got trillions of dollars vested in old languages and code. The cost to replace unsafe languages is unfathomable and there’s a prevailing attitude that we shouldn’t fix what’s not broken (even though we know it is broken in the back of our minds).
I think it’s going to take a couple generations to gain the momentum needed to overturn all the precedents that got us here.
Most of us aren’t inclined to replace stuff that we know and works, even if the new is better.
I feel it’s almost premature to be discussing Rust as a 100% viable alternative, it seems it’s well short of the coverage needed to do the lot and probably will remain that way for some time. Not every bit of code has problems solved by Rust, Rust can’t solve every problem and like most languages probably never will!
Having said that, I’m in to it like many now are, with many many more to come.