I can hardly wait until mainstream hardware catches up to Solaris SPARC in 2015, or previous memory tagged architectures, to finally tame all those memory corruption issues, only written by bad skilled developers.
I'm aware people may downvote the hell out of this, but if they do they're the ones writing the bugs: it's not "bad skilled developers" it's everyone. Memory corruption is basically a language feature of C/C++.
It's best to not perpetuate the belief that it's dumb people because very few people think they're dumb and I've seen some absolutely amazing coders write some hilarious memory bugs. It just comes with the territory of those languages. It's not "if" it's "when".
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
After 50 years of the Morris worm, only C Machines can fix the non existence of the mythical high skilled developer, and as Hoare predicted it is finally becoming a liability not to care about security.
Great quote. Nice to have memory tagging to help with the debug process these days. Not surprising to see these mistakes being made about 50 years later, as the fundamentals have not changed. Doing the same thing and expecting different results is, well, you know...
HWAsan is semi-hardware-accelerated memory tagging usable on most arm64 devices. MTE makes it much lower overhead for the debugging-oriented synchronous mode but also provides the asynchronous/asymmetric modes aimed at production usage. Asynchronous mode is near 0% overhead and asymmetric mode is overall comparable to the overhead existing barely useful legacy mitigations like SSP. MTE provides both bug detection in production for resolving the bugs and also hardening against exploitation. It would be nice if it had more bits, but it can already provide a lot of deterministic protections.
Highly recommend that any Android developer with a single native library shipped with their app gets a Pixel 8 or Pixel 8 Pro to use MTE for finding and debugging memory corruption bugs. One of the major advantages of MTE is that you can use heap MTE with instrumentation only added to the allocators (such as malloc) without building all the code with it. Stack allocation MTE of course requires instrumenting those stack allocations.
The person who made the mistake leading to the Bluetooth memory corruption bug we found is not at all at fault and neither is whoever reviewed it. It's a hard to spot race conditions leading to use-after-free. It was not immediately obvious what was wrong to us, but we suspected that it was a use-after-free since it usually is and then suspected that it was caused by a race after seeing what looked like a concurrent task being passed data without being passed ownership over the data with the responsibility to free it It's not clear that the function they called runs code concurrency without blocking until it completes, and the language makes writing safe code in extremely complex areas like Bluetooth near impossible. Google is doing a lot of the right things but not going far enough. It's mostly not a developer knowledge or skill issue. It's a tooling issue and we know how to fix these problems in a systemic way. It's viable to secure a small amount of memory unsafe code that's highly audited and receives special attention. It's not viable to write millions of lines of standard C++ without exploitable memory corruption bugs. The in-progress C++ safety guidelines, etc. are highly inadequate and presented as doing more than they actually provide. It's also too inflexible and highly unlikely to be broadly adopted. Rust is also a more usable, more production language that's a lot easier to learn. Rust developers can focus more on avoiding logic vulnerabilities and using the type system to prevent more of those, since there's underlying type/memory safety to build on. C++ doesn't have the foundation to build higher tiers of safely, since it's all built on sand.