SoylentNews is people
SoylentNews
Now that doesn't mean Linux stable kernel maintainer Greg Kroah-Hartman thinks Rust is magic:
At the Rust Week conference, the world's biggest Rust language conference, in Utrecht, Netherlands, Linux stable kernel maintainer Greg Kroah-Hartman opened by saying: "I'm here to talk about untrusted data and Linux, and how Rust is going to save us." After "a long month or two on the kernel security list," he pushed that point even further: "I'm going to make even a bolder statement and say, 'You are going to save Linux.' Sorry, it's all on you."
What he was talking about was the sudden flood of serious Linux security holes being discovered, such as Dirty Frag, Copy Fail, and Fragnesia, that have come to light thanks to the latest AI bug-detection programs.
As a result, Kroah-Hartman, who has "seen every single kernel security bug ever" since 2005, said the kernel team is now issuing "13 CVEs [Common Vulnerabilities and Exposures] a day, or something, something crazy." He thinks Rust is one of the few realistic ways to slash the class of bugs that come from C's traditional error-handling and resource-management pitfalls.
Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it."
Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."
Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever."
Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."
[...] Now, that doesn't mean he thinks Rust is magic. It's not. He cited one of the first Rust components merged into the kernel: QR code display logic used when the kernel crashes. "That logic was written in Rust. Famously, it had a memory bug. It was given a buffer and its size, and the rest of the st code never checked the buffer size... Could scribble all over memory, because Rust can crash just as bad as C." So, Rust "is not a silver bullet."
He's also not encouraging anyone to rewrite the Linux kernel in Rust. One attendee asked, "Do you actually encourage rewriting stuff that's already there in the kernel with [Rust]?" Greg replied: "No, we don't want rewrites, so unless you're the maintainer and owner of that file, just do it for new stuff. Leave existing C code alone, and let's evolve forward after that." He gave Binder, Android's core interprocess communication (IPC), as an example where both C and Rust implementations coexist temporarily to reach parity, after which "they're going to delete the C code, because I trust them, and they are the owners and maintainers of both those."
[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly."
Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds."
(Score: 3, Interesting) by turgid on Tuesday June 02, @09:28PM (1 child)
I remember when C was the cool new language on PCs in the 80s. There was a good reason for that. Computers at the time were very small and slow and the extra efficiencies of C were very important. It really was a thin layer above writing in assembly language. Also, it was the first high-level language in which a portable operating system (Unix) had been written. Pascal was a very nice language indeed, but it was in something of a sandbox. If you needed the extra power and control, C gave you that for free.
Modula-2 came out at a similar time and it was a great successor to Pascal. However, C++ came along and it was ostensibly a better C so it caught on.
C++ became a baroque monstrosity and something of a cult. The world is still suffering. Then someone came up with Rust, which is re-inventing Ada with curly brackets, slowly. They'll catch up eventually.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by Rich on Wednesday June 03, @01:04AM
I remember that I didn't see the point of C. You could do everything on an 8-bit Z80 in Turbo Pascal, or on the Mac in Lightspeed Pascal, and that even had a full object system. The code wasn't noticeably slower for any application I came across. And this was for CPUs with their roots in the 70s. If you really, seriously, needed the last cycle, you'd write the inner loops in assembly, which in turn was faster than C. C's pointer math features, even back then, were overestimated in their gains, and beyond that, C had nothing to offer over Pascal. But once C moved in, with it came the memory errors. It might have disturbed people that Pascal systems spat out complete applications in seconds, where the C ecosystens had all the hassle with preprocessor, compiler, archiver, and linker stages, which made them appear more "serious"..
Modula-2 was nice, but even more than an object system, and like Oberon that followed it, it lacked the ability to write native applications for most mainstream platforms. I think the Amiga had a Modula-2 with reasonable bindings, but to my knowledge, nothing for the Mac (and later the PC) existed. Around 1999, I worked for a Delphi shop, and even with my dislike for PCs, that was another dimension compared to the (early) C++ environment I had to deal with before. Now said C++ environment has caught up with me a few years later, and I've been maintaining it ever since. But I have the comparison to know how much better things could be. Rust has other downsides btw, it's the annoying ways the language dictates what is possible, and real-world developers then have to find their ways around these restrictions.