The Case for Memory Safe Roadmaps
Security guidance from the NSA and international partners urging a shift toward “memory safe” languages has reignited debate over how to reduce software vulnerabilities rooted in C and C++. Commenters weigh the practicality of incremental adoption of Rust and other safer languages against massive legacy codebases, performance‑critical domains, and ecosystems like graphics or kernels that are deeply tied to C/C++. Many argue that language choice, strong tooling, and architectural changes (e.g., microkernels, sandboxing) must complement developer training, since even highly skilled programmers struggle to avoid memory safety bugs at scale.
Adoption of Memory-Safe Languages in Systems/OS Code
- Discussion centers on how to bring memory safety into kernels and low-level systems.
- Rust in the Linux kernel is seen as promising but still tiny in footprint and early-stage, mostly in drivers.
- Strategy favored: gradual conversion of “edge” components to Rust rather than rewrites.
- Some argue microkernels or heavy segmentation (VMs, Qubes-style isolation) would have solved much of this earlier.
Language Choices and the NSA “Safe List”
- NSA’s appendix lists C#, Go, Java, Python, Rust, Swift as “memory safe,” which sparked debate.
- Many note that real-world ecosystems often call into C/C++ libraries, undercutting practical safety.
- Some wonder why Python is listed but not Ruby, JS, or Perl; explanation floated: popularity and AI/ML momentum.
Rust vs C/C++ (and Go/Swift)
- Supporters emphasize Rust’s “safe by default, unsafe in small, explicit regions,” shrinking the audit surface.
- Critics say for low-level work they hit
unsafeandMaybeUninitoften, feeling like C with extra ceremony. - C++ advocates argue RAII, smart pointers, custom integer types, sanitizers, and disciplined subsets can be “safe enough,” but others reply that history shows humans still introduce critical bugs.
- Go and Swift are noted as memory safe at the language level but with caveats: Go has data-race-based exploits; Swift and Rust add stronger concurrency guarantees.
Other Languages: Ada, Fortran, Java, JavaScript, Python
- Ada/ SPARK cited as strongly memory safe in safety‑critical domains (avionics, rail, defense), but tiny market share.
- Fortran largely confined to scientific computing; not seen as a major attack surface.
- Java called both a “pest fest” for exploits and, by others, mostly fine aside from notable incidents (e.g., log4j).
- JavaScript engines are hard to make fully safe due to JIT complexity; some mention safer implementations on JVM.
- Python itself is memory safe, but reliance on C/C++ extensions reintroduces risk.
Concurrency, Undefined Behavior, and Limits of Safety
- Several argue that after memory safety, undefined behavior and integer overflow/underflow should be next targets.
- Rust’s defined overflow behavior (panic in debug, wrap in release, plus explicit checked APIs) is praised.
- Others point out that no language fully “solves” concurrency; Rust and Swift go furthest, but logic races remain.
Legacy Code, Training, and Tools
- Huge C/C++ legacy is viewed as the core problem. Many new systems are still started in these languages.
- Some propose stricter subsets (MISRA-style) and static analysis (Astree, Frama-C, etc.) to prove safety, but note cost and difficulty.
- Thread is skeptical that training alone can prevent memory bugs; even highly trained developers in regulated domains still ship them.
- AI is suggested as a future assistant for auditing C/C++ for memory issues rather than writing new code.
Threat Models, Air Gaps, and NSA Motives
- Participants stress that air-gapped or “offline” C code is not immune (Stuxnet cited); if air‑gapping seems necessary, memory-safe languages likely are too.
- Some cynically suggest NSA wants industry to move to shared runtimes they might target, while others counter that NSA also has strong incentives to harden U.S. infrastructure.