> We’ve begun by enabling hardened libc++, which adds bounds checking to standard C++ data structures, eliminating a significant class of spatial safety bugs.<p>Well, it's 2024 and remember arguing this 20+ years ago. Programs have bugs that bounds checking catches. And making it a language built-in exposes it to compiler optimizations specifically targeting bounds checks, eliminating many and bringing the dynamic cost down immensely. Just turning them on in libraries doesn't necessarily expose all the compiler optimizations, but it's a start. Safety checks should really be built into the language.
Dlang added array bounds checking 20 years ago. It's a huge win. As evidenced by the article noting that 40% of the memory safety bugs were spacial.<p>I used to have all kinds of problems with array overflows. I didn't make them very often, but when I did, they took a long time to track down. They've been gone for 20 years now.<p>Note that it would be easy to add it to C/C++:<p><a href="https://www.digitalmars.com/articles/C-biggest-mistake.html" rel="nofollow">https://www.digitalmars.com/articles/C-biggest-mistake.html</a><p>It would be the most <i>useful</i> and cost-effective enhancement ever.
Game developers have been doing this since forever, its one of their main reasons to avoid the STL.<p>EASTL has this as a feature by default, and unreal engine container library has the boundchecks enabled on most games. The performance cost of those boundchecks in practice is well worth the reduction of bugs even on performance sensitive code.
> Hardening libc++ resulted in an average 0.30% performance impact<p>Maybe what really happened is that compiler technology has improved such that they are able to remove most redundant checks, such that it only costs 0.30% today. I can imagine things going the opposite direction 20 years ago, as in "we removed some bounds checks and gained X% of performance".
> We first enabled hardened libc++ in our tests over a year ago. This allowed us to identify and fix hundreds of previously undetected bugs in our code and tests.<p>That's something
I wonder if google really never had this turned on before? Like this has been available in the C++ standard library for decades(normally as a debug feature to catch errors in development, but some implementations such as MS support it in release also).<p>Might explain why they claimed 70% of exploits were memory related..
> The safety checks have uncovered over 1,000 bugs<p>In most implementations of the standard library, safety checks can be enabled with a simple #define. In some, it's the default behavior in DEBUG mode. I wonder what this library improves on that and why these bugs have not been discovered before.
PSA: Perhaps this is stating the obvious, but if you want bounds checking in your own code, start replacing T* with std::span<T> or std::span<T>::iterator whenever the target is an array.
>> spatial safety vulnerabilities represent 40% of in-the-wild memory safety exploits<p>Rust advocates tend to turn stats like this into “40% of all security issues are memory safety”, which sounds very similar but is false.