I am incredibly happy that Apple has added MTE support to the latest iPhones and perhaps the M5 chips as well (?). If that’s the case I don’t think any other personal computers have anything close to Apple machines in terms of memory safety and related topics (Secure Enclave etc).
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.
abalone
23 hours ago
[ - ]
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]
It's MTE4. The "enhancements" mostly make it easier for Apple developers to hack XNU into continuing to operate with MTE.
astrange
19 hours ago
[ - ]
It's more like MTE was originally intended as a debugging tool (like ASan), and MTE4 makes it work as a security hardening measure.
commandersaki
22 hours ago
[ - ]
Do you know if macos has the changes needed to make use of MIE with M5? I assume that it has with iPadOS.
contact9879
19 hours ago
[ - ]
do you have a citation for M5 having MTE?
abalone
9 hours ago
[ - ]
I did primary research. I just bought an M5 Mac and confirmed by doing:
$ sysctl -a | grep MTE4
hw.optional.arm.FEAT_MTE4: 1
astrange
19 hours ago
[ - ]
It does.
musicale
23 hours ago
[ - ]
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?
pjmlp
24 seconds ago
[ - ]
As mentioned elsewhere, Solaris SPARC and Linux on SPARC since 2015.
throwawaymaths
21 hours ago
[ - ]
sel4 ships with memory safety on by default.
accelbred
16 hours ago
[ - ]
Pixels with GrapheneOS also use MTE for security hardening
pjmlp
13 hours ago
[ - ]
As usual in these threads, a heads up to Solaris SPARC ADI, and Oracle Linux on SPARC, securing C code since 2015.
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.
It's little sad that the SPARC arch is no more and even after 10 years, we still don't have this feature in mainstream CPUs.
It is still around, although only a few care about it.
tempaccount420
22 hours ago
[ - ]
Sooo, less reasons (more excuses) for people to move from C++ to Rust?
dagmx
20 hours ago
[ - ]
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.
pjmlp
13 hours ago
[ - ]
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.
MangoToupe
9 hours ago
[ - ]
The code will still be incorrect; it's just that you'll know faster.
1718627440
22 hours ago
[ - ]
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.
kibwen
19 hours ago
[ - ]
Rust is already part of defense-in-depth. Despite its memory safety, Rust still turns on ASLR, guard pages, stack probes, etc.
For the second time though, they borked MPX design.
Madetocomment
7 hours ago
[ - ]
It's available on on pixel since pixel 8
e-dant
18 hours ago
[ - ]
It disappoints me to see hardware compensate for the failures of software. We should have done better.
thw_9a83c
12 hours ago
[ - ]
> 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.
amazingman
14 hours ago
[ - ]
How could we have done better without first knowing better?
pjmlp
13 hours ago
[ - ]
We have know better for decades, that is why Multics has a higher security score than UNIX, C flaws versus PL/I are noted on DoD report.
MangoToupe
9 hours ago
[ - ]
It also helps that nobody uses multics, so nobody has bothered to exploit it
pjmlp
9 hours ago
[ - ]
I can give other more recent examples, to prove the blindness of C community to security issues.
From which decade since C came to be, do you wish the example?
MangoToupe
8 hours ago
[ - ]
I'm certainly not defending C. I'm just saying multics is a horrible example.
pjmlp
8 hours ago
[ - ]
It is one out of many since 1958, starting with JOVIAL, how the industry has been aware of the security flaws that C allows for, which WG14 has very little interest in fixing, including turning down Dennis Ritchie proposal for fat pointers in 1990.
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.
Panzerschrek
15 hours ago
[ - ]
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.
thw_9a83c
8 hours ago
[ - ]
> Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake.
It's like saying airbags, seat belts (and other safety features) in cars are a terrible mistake because they just fix bad driving practices.
amazingman
14 hours ago
[ - ]
On the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.
MangoToupe
9 hours ago
[ - ]
I'm skeptical that you even can fully prevent exploitation of human error in software design. This just narrows one class of error.
a-dub
23 hours ago
[ - ]
wouldn't it be like a crime against the crown to not have a cheri like thing in arm?
commandersaki
22 hours ago
[ - ]
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.
wahern
18 hours ago
[ - ]
FreeBSD, kernel and base, was ported to CHERI, along with PostgreSQL.
> 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.
Sounds good for a clean slate but you couldn't seamlessly transition to it, which is why I said it was unappealing.
checker659
16 hours ago
[ - ]
> making it quite unappealing from an engineering standpoint
The other option being rewriting everything under the sun from scratch.
commandersaki
16 hours ago
[ - ]
Um, there's also Memory Tagging which is the topic of this post.
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.
astrange
15 hours ago
[ - ]
MTE (and PAC before it) store some metadata in previously unused pointer bits, so there are potential issues if you were already using those for something else.
Oh and if your program has memory bugs then you have to fix them of course.
ARM Memory Tagging: how it improves C/C++ memory safety (2018) [pdf]
(llvm.org)
71 points
by: fanf2
1 day ago
44 comments
javierhonduco
1 day ago
[ - ]
I am incredibly happy that Apple has added MTE support to the latest iPhones and perhaps the M5 chips as well (?). If that’s the case I don’t think any other personal computers have anything close to Apple machines in terms of memory safety and related topics (Secure Enclave etc).
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.
abalone
23 hours ago
[ - ]
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-...
summa_tech
22 hours ago
[ - ]
It's MTE4. The "enhancements" mostly make it easier for Apple developers to hack XNU into continuing to operate with MTE.
astrange
19 hours ago
[ - ]
It's more like MTE was originally intended as a debugging tool (like ASan), and MTE4 makes it work as a security hardening measure.
commandersaki
22 hours ago
[ - ]
Do you know if macos has the changes needed to make use of MIE with M5? I assume that it has with iPadOS.
contact9879
19 hours ago
[ - ]
do you have a citation for M5 having MTE?
abalone
9 hours ago
[ - ]
I did primary research. I just bought an M5 Mac and confirmed by doing:
astrange
19 hours ago
[ - ]
It does.
musicale
23 hours ago
[ - ]
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?
pjmlp
24 seconds ago
[ - ]
As mentioned elsewhere, Solaris SPARC and Linux on SPARC since 2015.
throwawaymaths
21 hours ago
[ - ]
sel4 ships with memory safety on by default.
accelbred
16 hours ago
[ - ]
Pixels with GrapheneOS also use MTE for security hardening
pjmlp
13 hours ago
[ - ]
As usual in these threads, a heads up to Solaris SPARC ADI, and Oracle Linux on SPARC, securing C code since 2015.
https://docs.oracle.com/en/operating-systems/solaris/oracle-...
https://docs.kernel.org/arch/sparc/adi.html
thw_9a83c
10 hours ago
[ - ]
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:
It's little sad that the SPARC arch is no more and even after 10 years, we still don't have this feature in mainstream CPUs.[1]: https://www.oracle.com/technetwork/server-storage/sun-sparc-...
pjmlp
8 hours ago
[ - ]
It is still around, although only a few care about it.
tempaccount420
22 hours ago
[ - ]
Sooo, less reasons (more excuses) for people to move from C++ to Rust?
dagmx
20 hours ago
[ - ]
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.
pjmlp
13 hours ago
[ - ]
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.
MangoToupe
9 hours ago
[ - ]
The code will still be incorrect; it's just that you'll know faster.
1718627440
22 hours ago
[ - ]
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.
kibwen
19 hours ago
[ - ]
Rust is already part of defense-in-depth. Despite its memory safety, Rust still turns on ASLR, guard pages, stack probes, etc.
qwertyuiop_
23 hours ago
[ - ]
Intel / AMD bringing this to x86 soon.
https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...
pjmlp
13 hours ago
[ - ]
For the second time though, they borked MPX design.
Madetocomment
7 hours ago
[ - ]
It's available on on pixel since pixel 8
e-dant
18 hours ago
[ - ]
It disappoints me to see hardware compensate for the failures of software. We should have done better.
thw_9a83c
12 hours ago
[ - ]
> 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.
amazingman
14 hours ago
[ - ]
How could we have done better without first knowing better?
pjmlp
13 hours ago
[ - ]
We have know better for decades, that is why Multics has a higher security score than UNIX, C flaws versus PL/I are noted on DoD report.
MangoToupe
9 hours ago
[ - ]
It also helps that nobody uses multics, so nobody has bothered to exploit it
pjmlp
9 hours ago
[ - ]
I can give other more recent examples, to prove the blindness of C community to security issues.
From which decade since C came to be, do you wish the example?
MangoToupe
8 hours ago
[ - ]
I'm certainly not defending C. I'm just saying multics is a horrible example.
pjmlp
8 hours ago
[ - ]
It is one out of many since 1958, starting with JOVIAL, how the industry has been aware of the security flaws that C allows for, which WG14 has very little interest in fixing, including turning down Dennis Ritchie proposal for fat pointers in 1990.
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.
Panzerschrek
15 hours ago
[ - ]
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.
thw_9a83c
8 hours ago
[ - ]
> Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake.
It's like saying airbags, seat belts (and other safety features) in cars are a terrible mistake because they just fix bad driving practices.
amazingman
14 hours ago
[ - ]
On the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.
MangoToupe
9 hours ago
[ - ]
I'm skeptical that you even can fully prevent exploitation of human error in software design. This just narrows one class of error.
a-dub
23 hours ago
[ - ]
wouldn't it be like a crime against the crown to not have a cheri like thing in arm?
commandersaki
22 hours ago
[ - ]
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.
wahern
18 hours ago
[ - ]
FreeBSD, kernel and base, was ported to CHERI, along with PostgreSQL.
> 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...
commandersaki
16 hours ago
[ - ]
Sounds good for a clean slate but you couldn't seamlessly transition to it, which is why I said it was unappealing.
checker659
16 hours ago
[ - ]
> making it quite unappealing from an engineering standpoint
The other option being rewriting everything under the sun from scratch.
commandersaki
16 hours ago
[ - ]
Um, there's also Memory Tagging which is the topic of this post.
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.
astrange
15 hours ago
[ - ]
MTE (and PAC before it) store some metadata in previously unused pointer bits, so there are potential issues if you were already using those for something else.
Oh and if your program has memory bugs then you have to fix them of course.