Not only does M5 have MTE, it has an "enhanced" version of it.

"We conducted a deep evaluation and research process to determine whether MTE, as designed, would meet our goals for hardware-assisted memory safety. Our analysis found that, when employed as a real-time defensive measure, the original Arm MTE release exhibited weaknesses that were unacceptable to us, and we worked with Arm to address these shortcomings in the new Enhanced Memory Tagging Extension (EMTE) specification, released in 2022."[1]

The enhancements add:[2]

* Canonical tag checking

* Reporting of all non-address bits on a fault

* Store-only Tag checking

* Memory tagging with Address tagging disabled

[1] https://security.apple.com/blog/memory-integrity-enforcement...

[2] https://developer.arm.com/documentation/109697/0100/Feature-...

Compiler/runtime support via clang and llvm should help I hope.

I'd like to get to the point where web browsers (for example) always run with memory-safe compilation and runtime features on every platform. OS kernels would be nice as well.

It will be nice to see more OSes ship with memory safety on by default for everything. Maybe OpenBSD is next?

Pixels with GrapheneOS also use MTE for security hardening

For the second time though, they borked MPX design.

Indeed, it was a radical feature in 2015. The marketing name for SPARC ADI was "Silicon Secured Memory" and the marketing material from that era [1] says:

   Some programming languages such as C and C++ remain vulnerable to memory corruption caused by software
   errors. These kinds of memory reference bugs are extremely hard to find, and victims usually notice
   corrupted data only long after the corruption has taken place. Complicating matters, databases and
   applications can have tens of millions of lines of code and thousands of developers. Importantly, errors
   such as buffer overflows are a major source of security exploits that can put an organization at risk.

[1]: https://www.oracle.com/technetwork/server-storage/sun-sparc-...

If you don’t mind moving the whole issue to runtime, then sure. The value of rust is that you catch these issues at compile time so you’re not releasing these sorts of bugs in the first place and aren’t reliant on the capabilities of the users machine to catch it for you.

When is Rust compiler moving away from LLVM, and GCC integration efforts, both written in C++?

That is the thing, there are endless products written in C++ since the 1980's, which no one is going to rewrite in safer languages.

The code will still be incorrect; it's just that you'll know faster.

Honestly it feels at the right abstraction layer too. With Rust you rely on correctness in translation, it is much better to have defense in depth than in breadth.

> It disappoints me to see hardware compensate for the failures of software. We should have done better.

I disagree. From a user's point of view, hardware-assisted memory safety is always beneficial. As a user of any software, you cannot verify that you are running a program that is free of memory access errors. This is true even when the software is written in Rust or an automatic memory-managed language.

I hope that one day I will be able to enable memory integrity enforcement for all processes running on my computers and servers, even those that were not designed for it. I would rather see a crash than expose my machine to possible security vulnerabilities due to memory access bugs.

I'm skeptical that you even can fully prevent exploitation of human error in software design. This just narrows one class of error.

How could we have done better without first knowing better?

I agree. The underlying hardware should be as simple as needed and thus be cheap and consume little power. Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake.

I always see cheri brought up and admittedly I know very little about it, except that the ergonomics appear poor requiring twice the storage for each pointer and ground up rearchitecting of the OS, making it quite unappealing from an engineering standpoint.