I’m super excited about this blogpost. The approach is so counterintuitive, and yet the results are so much better than anything else that we’ve tried for memory safety. We finally understand why. security.googleblog.com/2024…

Eliminating Memory Safety Vulnerabilities at the Source

Posted by Jeff Vander Stoep - Android team, and Alex Rebert - Security Foundations Memory safety vulnerabilities remain a pervasive threa...

security.googleblog.com

Sep 25, 2024 · 5:02 PM UTC

6
76
9
277
Replying to @jeffvanderstoep
That's very interesting. I had never thought this, yet after you explain it, it makes perfect sense.
22
Replying to @jeffvanderstoep
I wonder if there's yet another effect at play, which is that memory-safe wrappers/bindings force the underlying C/C++ code to get clear about its own semantics. This came up in the recent Rust-in-the-Linux-kernel kerfuffle, because it can feel *insulting* to existing C coders...
2
2
1
27
Replying to @jeffvanderstoep
That’s right things to do instead of rewriting everything. There are orgs and OSS projects haven’t integrate sanitizers/fuzzing into the QA process even though those tech exits more than a decade.
2
Replying to @jeffvanderstoep
Good writeup. Agree that vuln prevention > discovery > response. Curious about 1. How is "old" vs "new" code designated? 2. How is a specific vuln connected to only old or new code? Or am I misunderstanding 3. No counterfactual here right? ex to find/fix vulns in the old code
Replying to @jeffvanderstoep
This is true for any desired change of programming practice.
Load more