Hacker News Reader

Comment by lambdaone | Hacker News Reader

It's already been demonstrated to be insufficient; otherwise Apple software would now be impregnable. That's not to say these protections are a bad idea; they should be universal as they substantially reduce the existing attack surface - but the paper massively over-sells them as a panacea.

View on HN

Most server software these days is already written in memory-safe languages yet still has security vulnerabilities. If you reduce the vulnerabilities due to memory safety issues by, say, 90%, then there's nothing special about them anymore. On the other hand, memory-safe languages also don't fully eliminate memory safety issues as they depend on operations or components that may not themselves be fully memory-safe (BTW, Rust has this problem more than other memory-safe languages).

So a "panacea" in this context doesn't mean making the stack memory-safe (which nobody does, anyway) but rather making the vulnerabilities due to memory safety no more common or dangerous than other causes of vulnerabilities (and remember that rewriting software in a new language also introduces new vulnerability risks even when it reduces others). Whether these techniques actually accomplish that or not is another matter (the paper makes empirical claims without much evidence, just as some Rust fans do).

> BTW, Rust has this problem more than other memory-safe languages

Do you have a citation there?

I've run into a ton of memory safety issues in Go because two goroutines concurrently modifying a map or pointer is a data-race, which leads to memory unsafety... and go makes it wildly easy to write such data-races. You need to manually add mutexes everywhere for go to be memory safe.

Rust, on the other hand, I've yet to run into an actual memory safety issue. Like, I'm at several hundred in Go, and 0 in rust.

I'm curious why my experience is so different.

I think the key is "as they depend on operations or components that may not themselves be fully memory-safe" indicating Rust is used a far bit more to do interop with memory unsafe languages unlike Go or Java.

I sense OP's referring to raw pointer operations permitted by the unsafe dialect of the language.

It is more common (and/or more necessary) to either write unsafe code or call out to unsafe code written in some other language in Rust than in Java.

BTW, I wouldn't call a language that violates memory safety without an explicit unsafe operation a memory-safe language.

Rust compiler assumes that unsafe code still follows the borrow rules and optimizes code based on that. So if that is not the case, the consequences can be bad. For example, there was a bug in Rust OpenSSL bindings where OpenSSL had not documented the proper life time of some of the function arguments/return types. As the result unsafe code containing the call to OpenSSL C implementation violated Rust memory model leading to crashes.

But I agree that such problems are rare in Rust and Go races are much more problematic.

what vulnerabilities does rust introduce over c/c++?

Reply on news.ycombinator.com