Had a bunch of thoughts about the recent safety stuff, way more than fit in social media post... Blog post story time! (It's a bit of a ramble, sorry about that...)
https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/
Recently, several of my colleagues at Google shared the story of how we are retrofitting spatial safety onto our monolithic C++ codebase: https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html I wanted to have a bit of story-time about some of the strange ways that all this came to be, at least as I remember things. There are some really interesting developments that led us here, and some important lessons to learn from that history. Do note that this is just my retrospective memory. It’s entirely possible I’m misremembering some of it (let me know if so!). It’s also limited to my perspective, and others may have seen very different aspects of things (please share!).
C++ Safe Buffers — Clang 20
https://clang.llvm.org/docs/SafeBuffers.html
Discussions: https://discu.eu/q/https://clang.llvm.org/docs/SafeBuffers.html
I joined @durumcrustulum and @tqbf on the Security Cryptography Whatever podcast to talk about our latest blogpost:
https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Something that Thomas said in the podcast really stood out to me. He said “the blog post undersells it. …. This is a lot more interesting than it looks like on the tin.”
I agree with this. It feels like we discovered a game-changer not just in memory safety, but in security more generally - that doing something very practical results in major security improvements for non-obvious reasons. Focusing on new code is disproportionately effective, exponentially.
Thomas also said “And that observation about the half life of vulnerabilities, if that’s true, says something pretty profound about what the work looks like to shift to a memory safe future.”
Or as Deidre said: “You can get really big bang for your buck, which is if you have something new, just write it in the Rust or another memory safe language and make it interop with the rest of your project and you will in fact, get really good returns on mitigating your memory safe vulnerabilities, which is the majority of your vulnerabilities, period.”
Agreed. We’re already prioritizing differently based on this data. It was a fun conversation, and we believe that it applies to a lot more than just memory safety.
Proud to start sharing Google's strategy for tackling our remaining memory safety challenges: https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html
It's high level, but it outlines the long-term strategy. We'll be sharing more detailed posts in this series.
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. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
@dmnk and I wrote about how to incrementally adopt rust in existing firmware/bare-metal code bases.
https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html
#rust #firmwaresecurity #embeddedsecurity #cybersecurity #infosec #memorysafety
Chandler Carruth
C & C++ Weekly
jeffvanderstoep
Ivan Lozano