Skip to content

CONCEPT Cited by 4 sources

Memory safety

Definition

Memory safety is the property that a program cannot access memory it isn't authorized to — no use-after-free, no buffer overrun, no double-free, no uninitialized-read. In C / C++ this is the programmer's responsibility; in Rust (post-borrow-checker), Java/Kotlin, Go, etc. it is enforced by the language/runtime.

The practical importance for distributed-systems engineering is that the vast majority of new exploitable vulnerabilities in C/C++ systems stem from memory-safety bugs (use-after-free, bounds errors).

The key data point: new bugs come from new code

The Android team published a 2024 analysis (link) showing that the majority of newly discovered memory-safety vulnerabilities come from recently-written code, not from the aged core codebase. The operational consequence:

If you want to prevent memory-safety bugs, you don't need to rewrite the world — you just need to stop introducing new memory-unsafe code.

This reframes the trade-off from "huge C/C++ rewrite" to "adopt a safe language at the margin, for new work."

Case study: Aurora DSQL's Postgres extensions

The systems/aurora-dsql team initially assumed its Postgres extensions should be in C — lowest impedance mismatch with Postgres's C API surface. In a code review they found several memory-safety bugs in a seemingly simple data-structure implementation. Rethinking against the Android data:

  • Postgres's C core is battle-tested over decades — not where new bugs come from.
  • The team's new extension code would be the source of almost all their new memory-safety bugs.
  • Rust for extensions → no loss of control / performance, + elimination of that new-code bug class.

Even though Rust extensions interact tightly with Postgres's C API, the team built Rust abstractions that encode invariants into the type system that Postgres relies on conventions / comments for. Classic example: a C char* paired with a len field, whose safe-use contract lives in header comments. In Rust, a single String type encapsulates the invariant — making "violating the invariant" uncompilable rather than "commented-against."

Why Rust (vs. other safe languages) for this class of problem

  • Keeps GC off the hot path → compatible with concepts/tail-latency-at-scale constraints.
  • Zero-cost abstractions → high-level code compiles to efficient machine instructions; no runtime penalty for using safe abstractions.
  • C FFI ergonomics → can call and be called by existing C codebases (Postgres, libc) with careful wrappers.

Managed-language alternatives (Java, Kotlin, Go) deliver memory safety but not the GC-free property needed by DSQL's data plane.

Trade-offs

  • Learning curve: "with Rust you have the hangover first." DSQL's JVM-native team lost a few weeks early on, then shipped 10× the TPS of their tuned Kotlin version.
  • Unsafe blocks: necessary at C-FFI boundaries. The win is that they are localized and reviewable rather than pervasive.
  • Ecosystem: at the DSQL pivot to Rust control plane, the team's Rust internal libraries had matured enough (AWS Auth Runtime's Rust client was faster than its Java counterpart) to make the move viable — an earlier attempt would have been blocked by missing libraries.

Seen in

Last updated · 200 distilled / 1,178 read