Memory Safety

Original Article ↗ Hacker News Discussion ↗

Go and Memory Safety

  • Initial dispute over memorysafety.org listing Go as memory-safe centers on data races: torn multi-word writes to interfaces/slices can lead to type confusion and out-of-bounds or arbitrary memory reads/writes.
  • Some argue this violates the site’s own “out-of-bounds read/write” notion of memory safety; others say Go is “effectively” or “practically” memory safe because no real-world exploits from this have surfaced.
  • Distinction is drawn between:
    • Data races (can cause memory corruption) vs.
    • Race conditions (broader logic/ordering bugs not inherently memory-unsafe).
  • Comparisons:
    • Rust: prevents data races in safe code; race conditions can still occur but are not supposed to cause undefined behavior.
    • Python: with the GIL, data races don’t lead to memory corruption (ignoring C extensions).

Definitions and Degrees of Memory Safety

  • Thread splits between:
    • Strict view: any possible out-of-bounds access or UB from safe-looking code means the language is not memory safe.
    • Pragmatic view: what matters is whether exploitable memory corruption occurs in practice.
  • Debate on whether implementation bugs (e.g., CPython in C) should “disqualify” a language; some say no, or all languages would fail by that standard.

Rust, C/C++, and Fil‑C

  • C/C++ are described as memory-unsafe per their standards due to UB and constructs like unions and pointer arithmetic.
  • Others point out memory-safe implementations of C (e.g., Fil‑C, CHERI-based systems) that trap bad accesses, arguing this proves C can be implemented memory safely even if that’s not the norm.
  • Discussion of “nasal demons” UB and how Fil‑C disables many UB-based optimizations and kills the program on bad access.

Security Priorities and Rust Rewrites

  • Some participants are put off by what they see as Rust advocates’ fixation on memory safety and “snooty word games.”
  • Argument that PHP/WordPress, JavaScript/npm, and web supply-chain issues cause more real-world vulnerabilities than many C components being targeted for Rust rewrites.
  • Counterargument: Rust provides a concrete, deployable solution for a known class of bugs; large-scale rewrites are justified where performance and safety both matter, though cost–benefit will vary by codebase.

Concurrency and Hardware Support

  • Several comments suggest focusing on “concurrency safety” next, noting that no language can eliminate all race conditions.
  • Hardware aids mentioned:
    • SPARC ADI, ARM MTE, CHERI capabilities, which help detect spatial errors; temporal safety (use-after-free) is only probabilistically caught.
  • Some note that software (compiler + runtime) approaches currently deliver better performance than custom safe-ISA CPUs, and hardware features face adoption and mandate hurdles.

Java and Other “Safe” Ecosystems

  • Some find it odd the site largely ignores Java, which has memory-safe implementations of many protocols.
  • Pushback: JVM interop is awkward outside Java-centric stacks; Java also struggles with null-safety and invariant enforcement compared with newer type systems, though it handles null/out-of-bounds via exceptions reasonably in practice.
  • Comparison with Rust error handling: panics vs error-as-value are contrasted with Java exceptions.

MemorySafety.org, curl, and Org Transparency

  • Note that the site’s curl section is outdated/misleading: curl has dropped the Rust hyper backend but still uses Rustls; the site’s broader claim (“curl uses Rust in security-critical paths”) may still hold.
  • Concerns about the nonprofit’s annual report:
    • High-level categories (“ops & admin”, “advancement”) lack detail.
    • Questions about how much reaches programmers (e.g., via Prossimo) and whether maintainers of rewritten projects are compensated.
  • Some see the language list (e.g., privileging Rust, including Go, downplaying GC languages) as reflecting funders’ or advocates’ biases.