Hope other vendors will ship MTE in their laptop and desktop chips soon enough. While I’m very positive about x86_64 adding support for this (ChkTag), it’ll definitely take a while…
In my opinion a worthwhile enough reason to upgrade but feels like a waste given my current devices work great.
"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-...
$ sysctl -a | grep MTE4
hw.optional.arm.FEAT_MTE4: 1I'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?
https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...
https://docs.oracle.com/en/operating-systems/solaris/oracle-...
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-...
RC is a form of declaring shared use and is a parallel to shared_ptr in C++.
And yes there are escape hatches for safety that you can explicitly put yourself in. MTE would catch those at runtime , but you would still have prevented a ton at compile time.
There are also escapes you can find yourself in with memory tagging too.
Also, did you really just create a new account (with an inflammatory name) to crap on Rust while still not being able to address the points in my comment?
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.
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.
From which decade since C came to be, do you wish the example?
Note that C authors were aware of many flaws, hence why in 1979 they designed lint, which C programmers were supposed to use as part of their workflow, and as mentioned above proposed fat pointers.
Also note that C authors eventually moved on, first creating Alef (granted failed experiment), then on Inferno, Limbo, finalising with Go.
Also Rust ideas are based on Cyclone, AT&T Research work on how to replace C.
It was needed the tipping point of amount money spent fixing CVEs, ransomware, for companies and government to start thinking this is no longer tolerable.
My point is focusing on the language is inherently missing the point, which is simply incorrect code.
It's like saying airbags, seat belts (and other safety features) in cars are a terrible mistake because they just fix bad driving practices.
> We have adapted a complete C, C++, and assembly-language software stack, including the opensource FreeBSD OS (nearly 800 UNIX programs and more than 200 libraries including OpenSSH, OpenSSL, and bsnmpd) and PostgreSQL database, to employ ubiquitous capability-based pointer and virtual-address protection.
Most programs didn't require any changes at all. Even most pointer-integer-pointer conversions can be automatically handled by the toolchain and runtime. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...
The other option being rewriting everything under the sun from scratch.
Apple's implemented it as part of the umbrella MIE and eliminates a class of bugs, at least on the surface of their own software, and allows for incremental adoption and doesn't break compatibility with older binaries.
Oh and if your program has memory bugs then you have to fix them of course.