Mitigating Memory Safety Issues in Open Source Software • Hacker News Board

Re: Mitigating Memory Safety Issues in Open Source Software

#71

Post by simias » Thu, Feb 18, 2021, 1:52 PM UTC

stephen82 wrote: post #67

stephen82 wrote: post #9

Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.

I based my comment on Jens Gustedt's article [1] about adding a "defer" mechanism in standard C. Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth. In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied i…

Defer seems more like a solution to making cleanup easier and less error prone, preventing memory/fd/mutex leaks. It wouldn't significantly improve memory safety IMO. Adding a "slice" type with checked bounds (something basically every C codebase in existence ends up reimplementing somehow) would be a much greater improvement IMO.

But overall even though I still use C almost daily, I'm a bit skeptical of the committee's direction with these changes. They added half assed generics through macros, now a defer mechanism and a bunch of other stuff that's, IMO, out of scope for C. People have already tried to make a "better C" with all these bells and whistles, it's called C++, and it's still mostly backward compatible with C.

IMO C should be considered to be in "maintenance mode" these days. And again, my IRL job involves writing a lot of it, so it's not like I don't care about it.

Re: Mitigating Memory Safety Issues in Open Source Software

#72

Post by cp9 » Thu, Feb 18, 2021, 1:57 PM UTC

choeger wrote: post #57

While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity. There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. I'd say such an initiative needs a long-…

> There is a python library that recently switched to rust (partially) and now cannot be build on several platforms.

there comes a point where we can't let dependencies on Amiga or DEC Alpha (companies/platforms that haven't existed in literal decades) hold the rest of us back. If someone wants to port rust/llvm to those platforms more power to them, but the rest of us don't need to suffer. The only platform that actually matters that was negatively effected by that change is musl/alpine because there aren't musl wheels available and you have to build the rust part from source.

Re: Mitigating Memory Safety Issues in Open Source Software

#73

Post by paavohtl » Thu, Feb 18, 2021, 1:59 PM UTC

Zababa wrote: post #70

simias wrote: post #66

Earlier quoted context omitted.

IIRC Zig isn't memory safe though, is it? If not it seems like a bad choice if the explicit purpose is to mitigate memory safety issues...

I think this is the issue tracking memory safety in Zig: https://github.com/ziglang/zig/issues/2301

Has any language successfully added memory safety as a "feature" after the initial release? To me memory safety seems like a fundamental aspect of a language that is very hard if not impossible to change afterwards, without so many breaking changes that you essentially in the end have created a new programming language.

Re: Mitigating Memory Safety Issues in Open Source Software

#74

Post by bachmeier » Thu, Feb 18, 2021, 1:59 PM UTC

emteycz wrote: post #52

beckman466 wrote: post #37

Earlier quoted context omitted.

[flagged]

They're literally funding an organization that will take software to the next level and share it with the world, what more do you want?

A rewrite is not taking it "to the next level". It provides a new version in a new language that does the same things, and if things go according to plan, will have fewer safety issues. There's nothing that binds them to maintain any of these projects. Given Google's history, it's irresponsible to not consider long-term maintenance and other issues.

Re: Mitigating Memory Safety Issues in Open Source Software

#75

Post by notpygame » Thu, Feb 18, 2021, 2:00 PM UTC

The security information about C and curl is a bit outdated in the post, and recent research shows Rust does not solve the memory safety issue.

The "recent study" quoted in the article was published at the beginning of 2019, using older data.

Current vulnerability data shows that curl has very much limited the risk of memory safety issues. How many reported security vulnerabilities in the last two releases of curl? Zero so far. You have to go back 9 months before you find one expired-pointer derefence issue resulting in potential data being sent to the wrong connection in rare circumstances and configurations. Which is a logic error that could happen in Rust too.

To quote from a Oct 2020 study on Rust safety - "Our study results reveal that while Rust successfully limits the risks of memory-safety issues in the realm of unsafe code, it also introduces some side effects. In particular, most of the use-after-free and double-free bugs in our data set are related to the automatic drop scheme associated with the ownership-based memory management model." -- "Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs"

They study 60 Rust memory safety vulnerabilities.

As you can see not only does Rust not solve the memory safety problem, it has other issues. Additionally the old research quoted misleads people about the current status of reported memory safety issues in curl.

Re: Mitigating Memory Safety Issues in Open Source Software

#76

Post by trynton » Thu, Feb 18, 2021, 2:02 PM UTC

"bugs would have been completely prevented by using a memory-safe language"

Relying on safe languages isn't going to work as the defect resides in the Memory Management Unit. You would think by now these 'integrated' 'innovators' could come up with a MMU that provides total process isolation.

Re: Mitigating Memory Safety Issues in Open Source Software

#77

Post by userbinator » Thu, Feb 18, 2021, 2:10 PM UTC

enriquto wrote: post #6

semi-conspiracy theory: the main goal of this rewriting is to have less and less infrastructure depending on GPL and AGPL-licensed code

My semi-conspiracy theory: "safe" languages also make it harder for things like jailbreaks and other defeats of user-hostile "protections", allowing Big Tech to maintain control, so making them popular is very much in their interest. It's like how every utopian vision for society turns into a dystopian one.

"Insecurity is freedom."

Re: Mitigating Memory Safety Issues in Open Source Software

#78

Post by nojito » Thu, Feb 18, 2021, 2:11 PM UTC

lullibrulli3 wrote: post #15

nojito wrote: post #13

Earlier quoted context omitted.

Most of those project authors refuse to rewrite or adopt memory safe languages in their projects.

No reason no exclude them in the first place.

Sure, but the internet shouldn't be too upset when a fork happens with a version that has feature parity and is memory safe.

Re: Mitigating Memory Safety Issues in Open Source Software

#79

Post by rational_indian » Thu, Feb 18, 2021, 2:13 PM UTC

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

>Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare.

Maven != Cargo

> C++, on the other hand, has a variety of choices for build systems.

None of which even remotely approach the ease of use and maintainability of the Cargo build system.

> once you need to build something that the default build system doesn’t support, you’re in big trouble.

Cargo can build arbitrary dependencies using the build.rs build mechanism.

Re: Mitigating Memory Safety Issues in Open Source Software

#80

Post by pornel » Thu, Feb 18, 2021, 2:14 PM UTC

tediousdemise wrote: post #63

Is there a reason why some developers prefer Rust over C++? I often hear that it’s because of Cargo, but in my experience, universal build systems and package managers end up not really solving the problem they are designed to solve, and are a huge attack vector. Anyone who’s tried to deploy their own complex Maven project knows that it’s a true nightmare. C++, on the other hand, has a variety of choices for build sy…

Variety of choices for C++ end up causing fragmentation, and all choices are flawed in some way. If you choose Cmake, someone will tell you how much it sucks, and you should have used Meson. You choose Meson, people will complain that it needs Python, or Bazel needs Java, or why bother with any of them if Makefile is good enough, and so on in circles forever.

OTOH Cargo is the only option for Rust projects. There's nothing to bikeshed about. Everyone has it and knows how to use it.

Apart from that the project is about memory safety. Companies like Google, Microsoft, and Mozilla already have huge C++ codebases, top engineers with lots of C++ experience, spent tons of effort on making it safe, and still weren't happy with the results.