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.
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.
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.
> To make it fast you need simd, which implied using unsafe
Is just false. There are multiple safe SIMD libraries for Rust that can exploit the full SIMD potential. Only very rarely they require unsafe for maximum performance and only to avoid bound checks.
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"
To be clear, this is not due to the borrow checker at all, Rust does not have the tooling to statically determine the absence of logic bugs. What it has is the necessary programming language features to manage much more complex systems through abstraction and modeling.
Like are we empirically seeing less Rust CVEs? Adjusted for popularity of software and perhaps age of software.
surprisingly that’s almost not a strawman, I’d support an argument like that, and it’s how medicine works
if a cancer treatment is discovered, it needs to be trialled for side effects, and actually chemotherapy can have side effects that are worse than the cancer, it’s entirely possible for chemo to weaken the immune system and thus increase colds.
so hillariously, yes, that’s almost what I’m saying. but to be precise I’m not saying we shouldn’t cure cancer or solve bugs, just saying that solving one kind of issue doesn’t prove the tech is beneficial overall, and the more generic the problem being solved, the more likely the panacea will fail or have side effects
Vibe code aside I feel targeted rewrites are becoming more and more justified.
The Linux maintainers have been extremely conservative with the Rust introduction but after the endless CVE apocalypse they might be more receptive.
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.