Conversation

I disagree. We still haven't succeeded in making memory safety considered a base foundation. People are still making new languages that aren't memory safe, and they're getting popular.

Quote Tweet

edef

@edefic

Jul 24, 2021

memory safety is not a big deal in the same sense that not dying from the black plague is not a big deal—you're probably going to have a hard time producing great works if it's a problem left unsolved, but it's also mere foundation

Show this thread

146

Replying to

i can think of … Jonathan Blow's language (which doesn't seem of sufficient importance to bother remembering the name), and … Nim?

Replying to

and

i thought nim was “as safe as rust” (e.g. has some mechanism for restricting/explicitly annotating i safety)?

Tony "Abolish ICE" Arcieri

Replying to

and

I hesitate to even opine on this topic as it seems hotly debated and I don’t really know anything about Nim, but I’ve seen this mentioned in the past github.com/nim-lang/Nim/w

Replying to

and

that parses as "memory-safe in debug mode with sanitisers", which is on par with C/C++

Replying to

C and C++ can't be made memory safe with sanitizers. ASan only reliably detects linear overflows, not an arbitrary read/write from one object into another. A production implementation of even inter-object bounds safety for C is unavailable let alone temporal safety support.

Replying to

ASan relies on tracking which memory is in use with a shadow map representing chunks of memory with bits and has redzones around objects along with a quarantine for recently freed memory limited by how much memory you're willing to burn on it.

Replying to

It would be really cool if Clang had a switch to enforce memory safety but doing it efficiently and accurately likely requires having 128-bit or larger pointers which means having a different ABI. It could probably be done with ~30% performance overhead + fat ptr memory overhead.

Replying to

Yeah, to me the interesting question is how much perf overhead do you have before it's more expensive than just using a conservative tracing GC.

Replying to

You can use mostly-precise GC for C if you use a very strict interpretation of the standard with the same rules for pointer provenance, etc. Clang/GCC use to optimize for enforcing a safe memory model instead. It's entirely possible to implement standard C that way on top of JVM.

Replying to

chrisseaton.com/plas15/safec.p is a paper that I read about this years ago. As far as I can tell, this exists in a production usable form via GraalVM now: graalvm.org/security-guide It's only available with GraalVM Enterprise though and I assume that's an expensive paid Oracle product.

10:49 PM · Jul 25, 2021Twitter Web App

Replying to

WebAssembly could have provided bounds/temporal safety but instead all they did is provide a protected call stack and CFI. It's much coarser-grained than Clang CFI because it uses WebAssembly types instead of C types. They're missing nearly all the traditional mitigations too.

Replying to

Every new ABI is an opportunity to provide inter-object bounds/temporal safety at relatively low (< 25%) cost. It probably would have severely hindered WebAssembly adoption but it was still an explicit choice. Same goes for every new architecture choosing to keep being unsafe.