Google is funding the Internet Security Research Group (ISRG) to sponsor the Rust for Linux organization. Money will be funneled from la GOOG’s bottomless coffers to pay Miguel Ojeda as a full-time developer.
The idea is to write some new Linux components in the Rust language (think: drivers and such). There’s also the possibility of rewriting some risky C code in this up-and-coming, memory-safe language.
Get off my lawn, with your trendy flavor of the month. In this week’s Security Blogwatch, we look to see if we should believe the hype.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: The future of cloud?
What’s the craic? Jim Salter reports—The ISRG wants to make the Linux kernel memory-safe with Rust:
ISRG—parent [of the] Let’s Encrypt project—has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts. … Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself.
Using Rust for new code in the kernel … potentially decreases the number of bugs lurking in the kernel. Rust simply won’t allow a developer to … create the potential for buffer overflows—significant sources of … security issues in complex C-language code.
ISRG … has worked closely with Google engineer Dan Lorenc and that financial support from Google itself is critical to sponsoring Ojeda’s ongoing work. … Ojeda’s work is the first project to be sponsored under the ISRG’s Prossimo banner, but it’s not the first step the organization has taken for greater memory safety. Previous initiatives include a memory-safe TLS module for the Apache web server, a memory-safe version of the curl data transfer utility, and rustls—a memory-safe alternative to the ubiquitous OpenSSL.
Speaking of Google, Stephen Shankland speaks of Google backs Linux project:
Google [is] funding a project to increase Linux security by writing parts of the operating system’s core in the Rust programming language. … Google is paying for the contract, which is being extended through the [ISRG].
Such a change would mark a major technological and cultural shift [in Linux—a] project that’s become foundational to Google’s Android and Chrome operating systems as well as vast swaths of the internet. … Adding Rust modules to the Linux kernel would improve security by closing some avenues that hackers can use.
Google already has taken some early steps to make it possible to use Rust for Linux Android. Getting buy-in at the highest levels of the Linux kernel project means many other software projects could benefit, too. … The goal of the Linux on Rust project isn’t to replace all of Linux’s C code but rather to improve selective and new parts.
But why? The ISRG’s executive director, Josh Aas, explains—Supporting Miguel Ojeda’s Work on Rust in the Linux Kernel:
When we think about what code is most critical for today’s Internet, the Linux kernel is at the top of the list. Bringing memory safety to the Linux kernel is a big job, but the Rust for Linux project is making great progress. … We’ve been watching Miguel’s work with great interest.
The Linux kernel is at the heart of the modern Internet, from servers to client devices. It’s on the front line for processing network data and other forms of input.
Vulnerabilities in the Linux kernel can have a wide-ranging impact, putting security and privacy for people, organizations, and devices at risk. Since it’s written largely in the C language … memory safety vulnerabilities such as buffer overflows and use-after-frees are a constant concern. [With Rust] we can entirely eliminate memory safety vulnerabilities.
ISRG is the 501(c)(3) nonprofit organization behind Prossimo and Let’s Encrypt. We are 100% supported through the generosity of those who share our vision for ubiquitous, open Internet security.
Is this a good idea? clank75 says yes:
I’ve been programming Rust for [work] for about a year now, and have to say I’m a fan. … There is undoubtedly a learning curve, but it’s well worth it.
The state of frameworks is somewhat problematic, though. Not a lack of them, rather a proliferation — and they’re almost all immature and rapidly moving targets with unstable APIs. This leads to a very particularly Rust form of dependency hell. … This is probably less of an issue in something like Linux kernel development.
All in all, two thumbs up: Rust will be good for the kernel, and more developers using Rust will be good for Rust.
But lkcl says no, no, and thrice no:
It does not matter how good Rust is, this is an extremely bad idea: All developers must now learn:
1) secure programming techniques in Rust
2) secure programming techniques in C
3) best kernel practices in Rust
4) best kernel practices in C.
Not only that, but Rust is a moving target. And, worse [it] relies on a distribution system that is not properly linked to a web-of-trust.
Wait. Pause. I thought Google was in love with Go? mrweasel finds it weird:
That was a bit weird for a time, every time someone mentioned Go you’d get, “You should try Rust.” … The two camps seem to have determined that the two languages are aimed at different types of developers and the there is a place for both.
But aren’t memsafe languages terribly restricting? Not necessarily, argues DaveSimmons:
Rust is usually safe, except when you mark a section of code as unsafe because you need to do unsafe things. Some of the built-in library is in unsafe blocks because it can’t be in safe mode.
That’s still better than C/C++ though, because it’s safe by default. You must explicitly say you want to do something unsafe, and those sections of code can be tested more thoroughly.
It’s still impractical to do logic-based verification of code at the scale of full applications, but if you can confine the unsafe code to small parts those parts might be verifiable as correct.
Horses for course, eh? Here’s ArmoredDragon:
I’ve watched C programmers claim that it’s easy to avoid security vulnerabilities by just planning your code better. I’ve also watched C programmers complain about Rust because it forces you to plan your code better.
The thing with Rust is it guarantees that you can’t make certain kinds of mistakes that C offers zero guarantees against. At best you can have a compiler that performs code analysis to look for bugs, but there are never any guarantees.
Meanwhile, are you old enough to be thinking what bubbasnmp’s thinking?
One of the main advantages to working with Rust is that it never sleeps.
The moral of the story?
One to watch. And if you’re already watching Rust, this could be its chasm-crossing moment.
After replacing C, will Rust replace Go?
Previously in “And finally”
You have been reading Security 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@example.com. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
This week’s zomgsauce: Diego Delso / delso.photo (cc:by-sa)