Eliminating Memory Safety Vulnerabilities at the Source

Original Article ↗ Hacker News Discussion ↗

Android’s move to write new low-level components in memory-safe languages like Rust and Kotlin is credited with cutting memory safety vulnerabilities by roughly 60% without rewriting the existing C/C++ codebase. Commenters highlight research showing that most exploitable bugs live in recently written or modified code, arguing this justifies focusing security efforts and safer languages on new features rather than risky full rewrites. The thread also explores trade-offs around interoperability with C/C++, performance, developer productivity, and whether language changes alone are enough without better processes for preventing other major classes of security bugs like injection attacks.

Impact of using memory‑safe languages for new code

  • Central takeaway: you don’t need to “rewrite the world.” Shifting new development to memory‑safe languages (MSLs) can substantially cut memory safety bugs, even while legacy C/C++ remains.
  • Android data discussed: ~60% drop in memory‑safety issues from 2019–2023 without a mass rewrite, mainly by adding new Rust/Kotlin/Java code. Some ask why there’s a plateau and small rise in later years; the blog’s extrapolation for 2024 is seen as a bit “presentation‑driven.”
  • Several commenters note this is encouraging for large legacy C++ codebases that can’t realistically be rewritten.

Rust, interoperability, and language ecosystem

  • Rust is highlighted as the primary low‑level MSL replacement for Android’s C/C++.
  • Debate over Rust’s C++ interoperability: some argue it was “hostile” or slow to support rich C++ interop; others respond that full C++ ABI integration is technically hard and requires compiler‑frontend‑level support.
  • Tools like bindgen, cxx, and emerging interop efforts (e.g., crubit/crabi) are mentioned as pragmatic glue, contrasted with Swift’s tighter C/C++ integration.
  • Concern from shops with millions of lines of C++ that lack of smooth interop is a major barrier to adopting Rust incrementally.

Language trade‑offs: GC, performance, and safety

  • Commenters distinguish “memory safety” from “no GC”: Rust and Swift (ARC) are given as examples of high‑performance, non‑GC or hybrid approaches.
  • Others argue many domains are fine with GC languages (Java, Kotlin, C#, Go, Python, etc.) where engineer time and time‑to‑market dominate.
  • Go is seen as less suited for Android system components (runtime + GC, missing tagged unions), but used elsewhere at Google.
  • Some choose Rust over Go or other MSLs due to enums/sum types, stronger concurrency guarantees, or tighter control over allocation.

Vulnerability half‑life and old code

  • The article’s claim that vulnerabilities “decay exponentially” (most in new/changed code) resonates with people who see older code as “work‑hardened.”
  • Skeptics worry older code may simply be less scrutinized or sits in long‑tail, rarely exercised paths where serious bugs can linger.
  • Nuance: research cited looks at time to discover vulnerabilities; other data on time to patch and on unpatched vulns shows a long tail.

Security process vs language choice

  • One line of argument: memory‑unsafe languages plus weak processes guarantee ongoing defects; languages are “tools that make it too easy to fail.”
  • Another line: focusing only on memory safety ignores equally large or larger classes of bugs (e.g., injection), and the real root cause is lack of robust, enforced quality processes.
  • Many responses treat this as “both/and”: safe‑by‑default languages significantly reduce one high‑impact class of bugs and free up human effort to tackle harder, higher‑level security issues.