Retrofitting Temporal Memory Safety on C++ | Hacker News Reader

Retrofitting Temporal Memory Safety on C++

security.googleblog.com

19 pointspjmlp11 comments

Sometimes I think about the man-years of work dedicated to deficiencies in C/C++ that lead to results such as this. Conceptually, it's nothing but madness. Hacks upon hacks upon hacks upon hacks. And all of that because we've been unwilling to get rid of a programming model that we know is fundamentally broken?

With systems languages like Go and Rust things are slowly changing, but we're still bogged down in the swamp.

Feels like UNIX culture to me.

Go also has its own share of hacks by ignoring the history of language design since early 60's, while Rust remains to be seen how they will evolve the missing parts of error handling, co-routines, and system programming use cases from C and C++, where Rust still hasn't a mature alternative.

Both are definitly safer by default than either C or C++, however since Modula-2, Object Pascal and Ada, there were many other alternatives as well.

The OS vendors decided to go another route, and as we see here, the Chrome team isn't keen in following the Firefox route, rather improve the existing codebase.

This is the best documentation I could find from 2 years ago (with a tiny update), and at the same time Android added some Rust code:

https://www.chromium.org/Home/chromium-security/memory-safet...

I find it funny that the solution to C++'s memory woes involves retrofitting what's essentially a GC on top of it. Reminds me of the quote along the lines that all sufficiently complex codebases have a half-assed version of common lisp in it.

Several attempts have been made already, the problem is overcomming the community's resistance to have one in the box, recently they have removed the APIs introduced in C++11.

It is also interesting how Herb Sutter avoiding making the comparision between deferred deallocation and GC algorithms on his talk until the last section.

"CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”"

https://www.youtube.com/watch?v=JfmTagWcqoE

Does rust have one?

Yes, if you explicitly request it per object and use explicit clone for refs, but it doesn't handle reference cycles: https://doc.rust-lang.org/rust-by-example/std/arc.html

Cool stuff. Reminds me a bit of Boehm-Demers GC that can be used with C/C++ that made free() a no-op and used heap scanning to find garbage, though that wasn't security motivated.

That's an interesting approach, using hardware to correct for design flaws in software. I'd posit that it would be far better to use automatic reference counting and copy-on-modify, to better handle data that is shared in a multi-threaded environment.

Free Pascal uses such a system to manage strings, to good effect. You never have to deal with allocating, nor deallocating strings that can be a gigabyte in size. You can freely pass them by value or reference between functions and procedures and threads.

Of course you should use reference counting for things that actually need to be reference counted, and there's a standard mechanism in C++ for doing this (std::shared_ptr). However it's really only appropriate to use std::shared_ptr for things that actually have indeterminate lifetimes, because it (a) requires heap allocation and (b) requires the use of atomics. Most references/pointers in most C++ programs have simple scoping/lifetime requirements and don't require this overhead. If something retains a pointer to an object that is destroyed or goes out of scope, that can just as easily indicate that there is a logic error in the code retaining the dangling reference and therefore using std::shared_ptr or some other reference counting scheme isn't necessarily going to fix things.

C++ actually did have copy-on-write strings before C++11 (at least the std::string implementation in GCC/libstdc++ used CoW strings) but CoW implementations were made illegal because they caused a number of other problems.

I’ve been very pleased with Sean Parent’s `stlab::copy_on_write<T>` as a value-semantic mutable alternative to `std::shared_ptr<T>`. It has an explicit `write() -> T&` that makes it less magical than some CoW alternatives.

Reply on news.ycombinator.com