Hacker News Reader

Comment by veltas | Hacker News Reader

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.

View on HN

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"

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/

I strongly disagree with the idea that Rust makes it easier to hide logic bugs. Rust is a much more complicated system than C but allows software engineers to work at a much higher level of abstraction which generally reduces logic bugs. Of course, new projects will inherently have bugs but with Rust it is easier to achieve a higher level of rigor.

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.

At least it doesn't silently launch nuclear rockets, smaller bugs are manageable, like accidentally forcing everything to be UTF-8 is basically nothingburger.

until you can't delete a file because it's not valid UTF-8

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.

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?

> It sounds to me like you are saying we shouldn't treat common cold because cancer rates might increase

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

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

Sure. Where's my rust chromium rewrite then?

I wouldn't be surprised if Google is experimenting with exactly that right now.

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.

Reply on news.ycombinator.com