Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development [pdf]
5 comments
·June 28, 2025pizlonator
jart
Memory safety is basically the global warming of the software industry. Millions of careers depend on treating the problem and nobody wants the cure. I imagine Fil-C would be about as popular with the DoD as geoengineering / nuclear power are with environmentalists.
awaymazdacx5
reducing security incidents for modern software developments
charcircuit
A big thing missing is swapping out dependencies in unsafe languages for ones written in safe languages.
Usually there are only a couple places that actually deal with user controlled data, so switching to safe dependencies for things like making thumbnails for pdf files can be effective.
Edit: One more thing is compiling unsafe code to web assembly or other forms of sandboxing it was not mentioned.
null
Two big problems in this document:
- it conflates data race protection with memory safety, and it does so inconsistently. Java and C# are mentioned as MSLs and yet they totally let you race. More fundamentally, data races aren’t the thing that attackers exploit except when those data races do lead to actual memory corruption (like use after free, double free, out of bounds, access to allocator metadata etc). So it’s more precise to not mention data races freedom as a requirement for memory safety, both because otherwise languages like Java and C# don’t meet the definition despite being included in the list and because data races in the presence of memory safety are not a big deal from a security standpoint.
- The document fails to mention to mention Fil-C. It would be understandable if it was mentioned with caveats (“new project”, “performance blah blah”) but not mentioning it at all is silly.