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: 4, Interesting) by Rich on Tuesday June 02, @08:23PM (5 children)
In the 80s, I was under the impression that C was being forced onto the computing world by higher powers. Pascal was a perfectly fine systems programming language, as shown by the UCSD System, the Lisa, and the Mac. C was vastly inferior with regard to stability as it arrived, and it has hardly gotten better. The Pascal evoluton was unrivaled by anything C, through Turbo Pascal, Apple's Object Pascal, and finally Delphi. So the broad acceptance of C may well have been orchestrated, much as the Rust push is now. Nice conspiracy theories, anyway. :)
But aside from that, the C world has had a quarter of a century to get their stuff in order, and they didn't, so the C/C++ demise is self inflicted for the largest part. It would have not been hard to create a slightly modified language that's free from most of the breakage, as demonstrated by the Oberon experiment. Proper separation of call-by-reference and arrays, with range checks for the latter would have gone a long way. RTTI, ref-counting, and overflow checks would have sorted the rest. For convenience, they could have massaged the preprocessor to properly allow textual generics, and added shared code generics to the type system. Add a module system for compile speed, and you're done. (C# might have made it if they had proper GUI libs for all platforms and RC rather than GC (so realtime was covered). I once wrote a bit of stuff in the very similar Vala, and it was a pleasure.)
Instead we get C++ "concepts" to somehow, but only optionally, force the weird ways of the C++ committee on developers. While the developers just could use FreePascal/Lazarus, but instead (including me) follow (or have to follow) the herd. (Actually, even FreePascal developers follow the herd with their angled-bracket syntax for generics, rather than staying in the tradition of creating a Language.
(Score: 3, Interesting) by PhilSalkie on Tuesday June 02, @09:10PM (2 children)
Or we could put some time into making the C internal operations safer - have a look at Fil-C (based on clang) https://fil-c.org/ [fil-c.org]
From their website:
Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is checked. Fil-C has no unsafe statement and only limited FFI to unsafe code.
(Score: 4, Interesting) by turgid on Tuesday June 02, @09:31PM
See those "advanced runtime checks?" 30-40 years ago they were possible too (and other languages did them) but C did not. The reason was to get every last ounce of performance out of the system. Computers are now millions of times faster and that overhead is not a problem (mostly). I suppose it's about time someone put those features into C and C++ compilers. Before you know it, they'll be on a par with Turbo Pascal with array bounds checking turned on.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Rich on Wednesday June 03, @12:24AM
I did look at Fil-C before, and it's quite amazing. It does a good part of what Valgrind does, bot with a 2x instead of 100x speed penalty. The guy has built a super complicated runtime system to keep 100% syntax compatibility. It's fast enough that you could it for making some, but not all, existing codebases safe. Fine for server class applications. But in cases where you really want to know what's going on with every bit down to the instruction level (embedded), it's not the right choice. In the C world. this could really only be made safe (read UB free) with changes to the language itself.
(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.