undefined

points

[-]

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.

by athrowaway3z1 hours ago|

parent|

[-]

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.

by uecker1 hours ago|

parent|

[-]

The only question is to what extend this is relevant in reality, and how it compares to other efforts to avoid bugs.

by TOMDM13 hours ago|

prev|

[-]

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.

by Gigachad11 hours ago|

parent|

[-]

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.

by cesarb7 hours ago|

parent|

[-]

> 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.

by veltas11 hours ago|

prev|

[-]

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.

by herni11 hours ago|

parent|

[-]

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.

by veltas5 hours ago|

parent|

[-]

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/

by TZubiri8 hours ago|

parent|

prev|

[-]

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.

by 3OCSzk5 hours ago|

parent|

[-]

Are you saying by attempting to reduce certain types of bug category such as memory safety, other types of vulns would suddenly be increased because of it? It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase. And what do you mean by reactionary?

by Gigachad9 hours ago|

parent|

prev|

[-]

It’s also never been easier to replace C programs with safe alternatives.

by Aachen9 hours ago|

parent|

prev|

[-]

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"

by winwang8 hours ago|

parent|

prev|

[-]

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.

by 10 hours ago|

prev|

[-]

deleted