Conversation

"Rust doesn't check integer overflow" is one of the worst reasons I've ever heard to avoid it in favor of a non-memory-safe language. You can turn on Rust integer overflow checks with a compiler flag. You can't turn on memory safety in non-memory-safe languages.

351

Replying to

You could argue that compiling with asan is turning on memory safety. Sort of.

Replying to

and

Not at all since the only issues it finds reliably are linear overflows. It can't detect temporal safety issues when allocations are out of the quarantine and can't detect most out-of-bounds accesses but rather only special cases. It can't detect anything within objects either.

12:31 PM · Mar 30, 2022Twitter Web App

Replying to

and

HWAsan can detect a much broader range of issues between objects rather than only accesses outside of them, and doesn't depend as much on a quarantine but it's probabilistic and has a fairly decent chance of missing nearly any issue. Neither of these is close to memory safety.

Replying to

and

Hardware memory tagging on ARMv8.5 (not deployed in practice) / ARMv9 (deployed in the latest SoC generation by Qualcomm, at minimum) provides what HWAsan did via the ARM TBI (Top Byte Ignore) feature in a way that's meant to be suitable for production usage without a high cost.

Show replies

Replying to

and

Sure they aren’t the same but not that different either. The tools available for “memory unsafe” languages (like asan, valgrind) catch the vast majority of memory bugs. Acting like it’s the wild wild west for C/C++ is silly.

Replying to

and

They detect memory corruption when it occurs at runtime not the presence of the memory corruption bugs. If the current usage of the program doesn't trigger memory corruption with those bugs, there's nothing for them to detect. They're far from detecting the vast majority of them.

Show replies