What is "Memory Safety", really?

YOUTUBE HEXWRTEbj1I Oh baby, don't hurt me Don't hurt me No more

Rust's ownership system is capabilities-based. Is Rust then the new messiah, sent to save us from the hell of unsafe memory? Definitely not. We reprise Tiemoko Ballo's blogpost

- Rust largely prevents a major vector for information leakage and malicious code execution. - Stack protection: Classic stack-smashing is now an exception and not memory corruption; attempts to write past the end of a buffer will trigger a panic instead of leading to buffer overflow. - Heap protection: Bounds checks and panic behavior still apply to heap-allocated objects. In addition, the ownership paradigm eliminates dangling pointers, preventing Use-After-Free (UAF) and Double-Free (DF) vulnerabilities: heap metadata is never corrupted. - Memory leaks (meaning never freeing allocations, not over-reading data) are still possible if a programmer creates cyclical references. Compile-time static analysis does the enforcement, soundly reasoning about abstract states representing all possible dynamic executions. - References are always valid and variables are initialized before use: safe Rust doesn't allow manipulation of raw pointers, ensuring that pointer dereferences are valid. This means no NULL dereferences for DoS and no pointer manipulation for control flow hijack or arbitrary read/write - Data races are completely eliminated: Rust's ownership system ensures that any given variable can only have one writer (e.g. a mutable reference) at any given program point, but an unlimited number of readers (e.g. immutable references). In addition to enabling memory safety, this scheme solves the classic readers-writers concurrency problem.

# Caveats

- Not all Rust code is memory safe: Satisfying the compiler's analyses is part of what makes implementing certain data structures, difficult to fully analyze for safety. Blocks of code marked as unsafe are manually-designated "blindspots" for the analyses, bypassing safety-specific checks since the programmer vouches for their correctness! - Around 1% of a typical Rust library by one estimate is unsafe. From a security audit perspective, that's a colossal reduction in attack surface for a major bug class. - Interior mutability can push borrow checks to runtime: the interior mutability pattern allows multiple mutable aliases to a single memory location so long as they're not in use simultaneously. It's a sidestep of the borrow checker, a fallback when the problem can't be reframed in an idiomatic way for powerful compile-time guarantees.

# Coda Tiemoko Ballo has more to say. I do wonder has he read Mark S. Millers Ph.D. thesis on eRights? Presenting Robust Composition