[AaronFriel]

I'm afraid "partially implemented" memory safety is also widely known in the offensive security industry as "not memory safe". Many people have fooled themselves into thinking there is a gradient with safer C++ abstractions, libraries in C, custom allocators, static analyzers, valgrind, etc.

[naikrovek]

the entire language is partially implemented yet you are judging it as if it is complete and set in stone.

Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

[nicoburns]

> Rust isn't even memory safe if you want to be THIS pedantic about it. the unsafe keyword exists in Rust, and it is often used.

In practice, Rust seems to be much safer. I've seen Jarred talking about segfaults in Bun. Those are practically unheard of in Rust programs, and indicative of the possibility of quite serious security vulnerabilities.

[AaronFriel]

Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler".

Safe APIs that contain unsafe blocks must still be proven correct, via Miri, a model checker, formal proof, etc. Any safe functions that violate memory safety are considered bugs. The limited number of unsafe functions exist as helpers to build safe APIs when the compiler's borrower checker is insufficient.

What this means is that to verify memory safety, one can restrict their search to unsafe blocks. And hypothetically if the Rust compiler were to get much smarter, it should be possible to prove to the compiler that those blocks are safe (via theorem prover, perhaps?) and remove the "unsafe" declaration.

In most languages, there is no such distinction between the "memory safe" common set users ought to use and the subset that has to be verified independently. Neither Zig, C, C++, nor even Go have a clear delineation between safe and unsafe code.

[naikrovek]

> Unsafe is perhaps poorly named, and several Rust core team members have commented as such. It doesn't mean memory unsafe, it means "not checked by the compiler".

That's lack of memory safety when your memory safety work is done during compilation, as is the case with Rust.

[ksec]

Last time an Open Source project was using UnSafe it was getting attacked by Rust Evangelism Task Force.

[rileyphone]

Is there not a gradient though? Are C++ smart pointers equally as bad as regular old malloc? Can safer abstractions not render most buffer overflows impossible?

[AaronFriel]

I misspoke. Yes, security is on a gradient and the things I've listed have caught and prevented many, many bugs, but memory safety is a binary proposition. Those things have not made C++ "memory safe".

[cocoto]

There is definitely a gradient in safety and almost everybody agree with that. What is controversial is how much safety you actually need.

[throwawaymaths]

And it's not clear that safety has to be in the compiler: it could be in a static analysis tool, for example.

[AaronFriel]

I misspoke, there is a gradient in safety, but "memory safe" is binary.

[_vvhw]

There is in fact a spectrum with respect to memory safety. For example, temporal vs spatial safety.

Furthermore, no language is “memory safe” in the absolute sense. For example, not even the borrow checker can protect you from buffer bleeds.

[AaronFriel]

Despite the "How Safe is Zig"[1] blog post, it's false that there is a spectrum. A lack of temporal safety implies a lack of spatial safety, and vice versa.

If one can use a use-after-free, invalid write, time of check-time of use error to write a byte to an invalid location, the program's data structures are now in an inconsistent state, violating invariants required for "spatial safety" such as objects being the correct type, buffers and lengths being paired together correctly, etc.

Likewise, if one can accomplish a buffer overflow, a spatial safety violation, or an out of bounds write, then by definition they've made temporal violations as well. Writing objects out of bounds or arbitrary heap writes imply data races.

Offensive security folks use gadgets that exploit one to accomplish the other, as needed.

[1] https://www.scattered-thoughts.net/writing/how-safe-is-zig/

[_vvhw]

Thanks, that's a great insight!

Does it follow that the fact that temporal violations could be used to violate runtime spatial checks, therefore means that spatial safety in itself is entirely without value?

What are your thoughts also on buffer underflows? I ask since I take it you also work on offensive security.

[AaronFriel]

Alas, I don't work in offensive security but it's been a hobby of mine as an engineer to keep up to date. Some day, perhaps.

To be precise, I don't think the mitigations Zig has, which the author labels as "spatial safety", are entirely without value. Optionals & sum types, range checks are helpful.

Buffer underflows as in writing to negative indices? I wish I could go in a time machine and default early languages to saturating arithmetic instead of wrapping. Even Rust does wrapping arithmetic in release mode, in debug mode overflows will panic.