Comment by winwang
13 hours ago
It's okay guys, the authors simply don't know how to write good C. A real C programmer would not have shipped such a basic use-after-free bug. Rust is just a crutch.
13 hours ago
It's okay guys, the authors simply don't know how to write good C. A real C programmer would not have shipped such a basic use-after-free bug. Rust is just a crutch.
The fallacy is the idea that a Rust implementation would automatically achieve the same performance, and not resort to "unsafe" to be competitive, and then be open to exactly the same issues.
Illustrative example: This CVE in a Rust matrix transpose code: https://github.com/advisories/GHSA-5gmm-6m36-r7jh
Conceptually, there is not really anything much simpler than a matrix transpose. So how did they manage to create a bug? To make it fast you need simd, which implied using unsafe, and the dimension check to make it safe used unsigned integers that could wrap around. So they same bullshit as in C.
Your fallacy is that you present the comparison 'if' either of the two can be done poorly.
Rust can separate the question: "Is a set of functions is safe in a certain condition" from "using functions in that condition".
They are materially different. SIMD has a safe interface now.
The only question is to what extend this is relevant in reality, and how it compares to other efforts to avoid bugs.
With all the "Claude rewrote X in rust!" posts lately, I'm waiting on the inevitable Linux kernel rewrite post.
Vibe code aside I feel targeted rewrites are becoming more and more justified.
I wouldn’t be surprised if we start seeing individual drivers and subsystems move over.
The Linux maintainers have been extremely conservative with the Rust introduction but after the endless CVE apocalypse they might be more receptive.
> I wouldn’t be surprised if we start seeing individual drivers and subsystems move over.
Already happening. https://lwn.net/SubscriberLink/1102982/c3a3a2d4f17108c5/ "Removing binder.c" is an article from yesterday, about discarding the old C implementation of the Android Binder driver (used by every single Android phone) in favor of its Rust reimplementation.
Counterpoint, more than memory bugs exist, and everything's written in C. You're welcome to rewrite in Rust but you'll create countless bugs that aren't memory bugs that mostly already got fixed in the C version. I can't help but think things like fil-C are the most pragmatic route, despite performance costs, for most people relying on programs written in C.
This is a dumb argument imo. Critical vulnerabilities are mostly due to memory bugs (and not for a lack of other kinds of bugs). Most people relying on programs written in C (or even C++) should consider plans for migrating to software created with toolchains from this century. You cannot indefinitely carry on this tech debt.
Here are some CVEs identified in Rust coreutils [1]. These are mostly really trivial issues. I'd bet money that the nastier logic bugs are still in there and that the people who maintained the old C utils or helped identify the old bugs can find similar ones in these utils, although half these issues probably never appeared in the C version because Rust is much more complicated than C so makes it easier to hide logic bugs in plain site, looking at many of the issues in this article they seem like bugs that are extremely unlikely to get written in C, like accidentally forcing everything to be UTF-8, or aborting on routine errors.
[1] https://corrode.dev/blog/bugs-rust-wont-catch/
One issue with this argument is that, almost everything is memory, especially in C. It's not really descriptive. If you write a reactionary language like Rust, it may be possible that you just fix one type of issue (with an error type taxonomy that's not very refined), and end up with a language that does not necessarily cause less bugs and vulns, but that causes less vulns that can be classified as that type of issue, while increasing other types of bugs/vulns, either of an existing type, or of a new type that only exists in that new language.
Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.
1 reply →
It’s also never been easier to replace C programs with safe alternatives.
Yes, you'd introduce a lot of new bugs because the code is newly written[1], but eventually you'll get to the same maturity as today except you can't have all these devastating memory-handling-related vulnerabilities
The question is whether your software will be in use long enough to be worth the cost of change more than whether it's a good idea in the long run. For Linux, I'd argue that that's likely. At least new code would ideally be contributed in a safe language, where practically possible (there'll surely be places where you need to deal with memory as a kernel)
Relevant article: reducing memory vulnerabilities through a combination of memory-safe languages and an exponential decrease of bugs as existing code ages https://security.googleblog.com/2024/09/eliminating-memory-s..., from which I'll also quote my reference for [1]: "A large-scale study of vulnerability lifetimes published in 2022 in Usenix Security [...] found that the vast majority of vulnerabilities reside in new or recently modified code"
I'm not suggesting anything like "rewrite in Rust", at least not in general. I'm simply poking at the fact that use-after-free (and other such issues) are effectively deprecated classes of bugs.