4 ms·

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 s

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.

pron 2y ago
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).
- kobebrookskC3 2y ago
  what vulnerabilities does rust introduce over c/c++?
- TheDong 2y ago
  > 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.
  - commandersaki 2y ago
    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.
  - meltyness 2y ago
    I sense OP's referring to raw pointer operations permitted by the unsafe dialect of the language.
  - pron 2y ago
    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.
  - fpoling 2y ago
    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.

pron 2y ago

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

kobebrookskC3 2y ago
what vulnerabilities does rust introduce over c/c++?
TheDong 2y ago
> 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.
- commandersaki 2y ago
  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.
- meltyness 2y ago
  I sense OP's referring to raw pointer operations permitted by the unsafe dialect of the language.
- pron 2y ago
  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.
- fpoling 2y ago
  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.