Strap in, get ready for more Rust drivers in Linux kernel

Rust is alive and well in the Linux kernel and is expected to translate into noticeable benefits shortly, though its integration with the largely C-oriented codebase still looks uneasy.

In a hopeful coda to the recent maintainer drama that raised questions about the willingness of Linux maintainers to accommodate Rust code, Josh Aas, who oversees the Internet Security Research Group’s Prossimo memory-safety project, late last week hailed Miguel Ojeda’s work to advance memory safety in the kernel without mentioning the programming language schism.

“While our goal was never to rewrite the entire kernel in Rust, we are glad to see growing acceptance of Rust’s benefits in various subsystems,” said Aas. “Today, multiple companies have full time engineers dedicated to working on Rust in the Linux kernel.”

Our goal was never to rewrite the entire kernel in Rust …

Since at least September last year, when Microsoft software engineer Wedson Almeida Filho left the Rust for Linux project citing “non-technical nonsense,” it’s been clear that acceptance had limits. Tensions between Rust and C kernel contributors flared again in January over concerns about the challenges of maintaining a mixed language codebase – likened to cancer by one maintainer. Urged to intervene, Linux creator Linux Torvalds did so, making his annoyance known to both parties and prompting their departures as Linux maintainers.

Amid all that, Ojeda, who helms the Rust for Linux project, published a “Rust kernel policy” as a way to clarify that those contributing Rust code to the Linux kernel should stay the course and to underscore that Linux leaders still support the initiative.

According to Aas, the presence of Rust code is increasing in various Linux subsystems, including: PHY drivers, the null block driver, the DRM panic screen QR code generator, the Android binder driver, the Apple AGX GPU driver, the NVMe driver, and the Nova GPU driver.

“We expect that one of them will be merged into the mainline kernel in the next 12-18 months,” said Aas, pointing to remarks from Linux lieutenant Greg Kroah-Hartman last November suggesting that the availability of Rust driver bindings represented a tipping point that would allow most driver subsystems to start getting Rust drivers.

Once this happens, said Aas, “the goal of the effort will start to be realized: Products and services running Linux with Rust drivers will be more secure, and that means the people using them will be more secure, too.”

Security – in the form of memory safety – is Rust’s selling point.

Rust provides ways to avoid memory safety vulnerabilities that crop up in programming languages like C and C++ where manual memory management is allowed. Though other languages such as Python, Java, JavaScript, Swift, and C# are also considered memory safe, Rust has received most of the memory safety evangelism, partly because it’s suited for the sort of low-level, performance-sensitive code that for the past few decades has tended to be written in C and C++.

As we reported recently, the public adoration of Rust, and the public sector parroting of that message, has set off alarm bells in the C and C++ communities. Veteran C and C++ developers are not ready to call it quits, if that were even a plausible scenario.

Yet the future promoted by the Prossimo project, launched several years ago “to move the internet’s security-sensitive software infrastructure to memory safe code” and “to change the way people think about memory safety,” promises increasing marginalization and diminishing opportunities for C and C++ developers.

Earlier this week, Aas made it clear those prioritizing memory safety are keen to see C and C++ retired, even though there’s widespread acknowledgement that C and C++ will be around for years and will need to be maintained.

“Many of the most critical software vulnerabilities are memory safety issues in C and C++ code, and while there are ways to reduce the risk, including fuzzing and static analysis, memory safety vulnerabilities continue to plague the Internet,” said Aas in a write-up.

“The good news is that with the rare exception of code that must be written in assembly for performance and/or security reasons (eg, cryptographic routines), we know how to get rid of memory safety vulnerabilities entirely: write code in languages that don’t allow for those kinds of mistakes. It’s a more or less solved research problem, and as such we don’t need to suffer from this kind of thing any more. It can be relegated to the past like smallpox, we just have to do the work.”

Between evocations of cancer and smallpox, it sounds like the Linux and Rust communities still have some issues to work out. ®

READ MORE HERE