Google's Chrome Team Evaluates Retrofitting Temporal Memory Safety on C++

'C++ allows for writing high-performance applications but this comes at a price, security...' So says Google's Chrome security team in a recent blog post, adding that in general, 'While there is appetite for different languages than C++ with stronger memory safety guarantees, large codebases such as Chromium will use C++ for the foreseeable future.'

So the post discusses 'our journey of using heap scanning technologies to improve memory safety of C++.'
The basic idea is to put explicitly freed memory into quarantine and only make it available when a certain safety condition is reached. Microsoft has shipped versions of this mitigation in its browsers: MemoryProtector in Internet Explorer in 2014 and its successor MemGC in (pre-Chromium) Edge in 2015. In the Linux kernel a probabilistic approach was used where memory was eventually just recycled. And this approach has seen attention in academia in recent years with the MarkUs paper. The rest of this article summarizes our journey of experimenting with quarantines and heap scanning in Chrome.

In essence the C++ memory allocator (used by new and delete) is 'intercepted.'
There are various hardening options which come with a performance cost:
- Overwrite the quarantined memory with special values (e.g. zero);
- Stop all application threads when the scan is running or scan the heap concurrently;
- Intercept memory writes (e.g. by page protection) to catch pointer updates;
- Scan memory word by word for possible pointers (conservative handling) or provide descriptors for objects (precise handling);
- Segregation of application memory in safe and unsafe partitions to opt-out certain objects which are either performance sensitive or can be statically proven as being safe to skip;
- Scan the execution stack in addition to just scanning heap memory...

Running our basic version on Speedometer2 regresses the total score by 8%. Bummer...

To reduce the regression we implemented various optimizations that improve the raw scanning speed. Naturally, the fastest way to scan memory is to not scan it at all and so we partitioned the heap into two classes: memory that can contain pointers and memory that we can statically prove to not contain pointers, e.g. strings. We avoid scanning memory that cannot contain any pointers. Note that such memory is still part of the quarantine, it is just not scanned....

[That and other] optimizations helped to reduce the Speedometer2 regression from 8% down to 2%.
Thanks to Slashdot reader Hari Pota for sharing the link

Read more of this story at Slashdot.