3 ms·

ARM Memory Tagging: how it improves C/C++ memory safety (2018) [pdf]

73 points by fanf2 1y ago

javierhonduco 1y 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 1y 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/ https://security.apple.com/blog/memory-integrity-enforcement... [2] https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv8-9-architecture-extension?lang=en#md454-the-armv89-architecture-extension__FEAT_MTE4 https://developer.arm.com/documentation/109697/0100/Feature-...
  - commandersaki 1y ago
    Do you know if macos has the changes needed to make use of MIE with M5? I assume that it has with iPadOS.
  - summa_tech 1y ago
    It's MTE4. The "enhancements" mostly make it easier for Apple developers to hack XNU into continuing to operate with MTE.
    - astrange 1y 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.
  - contact9879 1y ago
    do you have a citation for M5 having MTE?
    - astrange 1y ago
      It does.
    - abalone 1y 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
      - PicardsFlute 1y ago
        Thank you for posting that. I was pretty sure the M5 was going to ship with MTE, but the last time I checked the documents, they still hadn't updated them (nor any mention of M5 having Apple10 in the metal feature tables). Some big features there that makes me want to upgrade!
- musicale 1y 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?
  - throwawaymaths 1y ago
    sel4 ships with memory safety on by default.
  - pjmlp 1y ago
    As mentioned elsewhere, Solaris SPARC and Linux on SPARC since 2015.
- accelbred 1y ago
  Pixels with GrapheneOS also use MTE for security hardening
a-dub 1y ago
wouldn't it be like a crime against the crown to not have a cheri like thing in arm?
- commandersaki 1y 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 1y 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-asplos-cheriabi.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...
    - commandersaki 1y ago
      Sounds good for a clean slate but you couldn't seamlessly transition to it, which is why I said it was unappealing.
  - checker659 1y ago
    > making it quite unappealing from an engineering standpoint The other option being rewriting everything under the sun from scratch.
    - commandersaki 1y 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.
qwertyuiop_ 1y ago
Intel / AMD bringing this to x86 soon. https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/ChkTag-x86-Memory-Safety/post/1721490 https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...
- pjmlp 1y ago
  For the second time though, they borked MPX design.
tempaccount420 1y ago
Sooo, less reasons (more excuses) for people to move from C++ to Rust?
- 1718627440 1y 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 1y ago
    Rust is already part of defense-in-depth. Despite its memory safety, Rust still turns on ASLR, guard pages, stack probes, etc.
- dagmx 1y 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.
  - rustdebacletime 1y ago
    [flagged]
    - dagmx 1y ago
      The use of RC is orthogonal to the memory safety guarantees of Rust. The use of RC and safety checking of it is handled at compile time, and only the refcounting aspect is runtime. 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?
e-dant 1y ago
It disappoints me to see hardware compensate for the failures of software. We should have done better.
- Panzerschrek 1y 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.
  - amazingman 1y ago
    On the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.
  - thw_9a83c 1y 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 1y ago
  How could we have done better without first knowing better?
  - pjmlp 1y 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 1y ago
      It also helps that nobody uses multics, so nobody has bothered to exploit it
pjmlp 1y 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-solaris/11.4/prog-interfaces/using-application-data-integrity-adi.html https://docs.oracle.com/en/operating-systems/solaris/oracle-... https://docs.kernel.org/arch/sparc/adi.html https://docs.kernel.org/arch/sparc/adi.html
- thw_9a83c 1y 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: 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. [1]: https://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-t7-m7-server-architecture-2702877.pdf https://www.oracle.com/technetwork/server-storage/sun-sparc-...
  - pjmlp 1y ago
    It is still around, although only a few care about it.
Madetocomment 1y ago
It's available on on pixel since pixel 8

73 points by fanf2 1y 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 1y 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/ https://security.apple.com/blog/memory-integrity-enforcement... [2] https://developer.arm.com/documentation/109697/0100/Feature-descriptions/The-Armv8-9-architecture-extension?lang=en#md454-the-armv89-architecture-extension__FEAT_MTE4 https://developer.arm.com/documentation/109697/0100/Feature-...
- commandersaki 1y ago
  Do you know if macos has the changes needed to make use of MIE with M5? I assume that it has with iPadOS.
- summa_tech 1y ago
  It's MTE4. The "enhancements" mostly make it easier for Apple developers to hack XNU into continuing to operate with MTE.
  - astrange 1y 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.
- contact9879 1y ago
  do you have a citation for M5 having MTE?
  - astrange 1y ago
    It does.
  - abalone 1y 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
    - PicardsFlute 1y ago
      Thank you for posting that. I was pretty sure the M5 was going to ship with MTE, but the last time I checked the documents, they still hadn't updated them (nor any mention of M5 having Apple10 in the metal feature tables). Some big features there that makes me want to upgrade!
musicale 1y 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?
- throwawaymaths 1y ago
  sel4 ships with memory safety on by default.
- pjmlp 1y ago
  As mentioned elsewhere, Solaris SPARC and Linux on SPARC since 2015.
accelbred 1y ago
Pixels with GrapheneOS also use MTE for security hardening

a-dub 1y ago

wouldn't it be like a crime against the crown to not have a cheri like thing in arm?

commandersaki 1y 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 1y 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-asplos-cheriabi.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904...
  - commandersaki 1y ago
    Sounds good for a clean slate but you couldn't seamlessly transition to it, which is why I said it was unappealing.
- checker659 1y ago
  > making it quite unappealing from an engineering standpoint The other option being rewriting everything under the sun from scratch.
  - commandersaki 1y 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.

qwertyuiop_ 1y ago

Intel / AMD bringing this to x86 soon. https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/ChkTag-x86-Memory-Safety/post/1721490 https://community.intel.com/t5/Blogs/Tech-Innovation/open-in...

pjmlp 1y ago
For the second time though, they borked MPX design.

tempaccount420 1y ago

Sooo, less reasons (more excuses) for people to move from C++ to Rust?

1718627440 1y 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 1y ago
  Rust is already part of defense-in-depth. Despite its memory safety, Rust still turns on ASLR, guard pages, stack probes, etc.
dagmx 1y 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.
- rustdebacletime 1y ago
  [flagged]
  - dagmx 1y ago
    The use of RC is orthogonal to the memory safety guarantees of Rust. The use of RC and safety checking of it is handled at compile time, and only the refcounting aspect is runtime. 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?

e-dant 1y ago

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

Panzerschrek 1y 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.
- amazingman 1y ago
  On the contrary, fixing pervasive and increasingly costly ecosystem issues in hardware is exactly the kind of innovation we need.
- thw_9a83c 1y 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 1y ago
How could we have done better without first knowing better?
- pjmlp 1y 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 1y ago
    It also helps that nobody uses multics, so nobody has bothered to exploit it

pjmlp 1y 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-solaris/11.4/prog-interfaces/using-application-data-integrity-adi.html https://docs.oracle.com/en/operating-systems/solaris/oracle-... https://docs.kernel.org/arch/sparc/adi.html https://docs.kernel.org/arch/sparc/adi.html

thw_9a83c 1y 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: 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. [1]: https://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/sparc-t7-m7-server-architecture-2702877.pdf https://www.oracle.com/technetwork/server-storage/sun-sparc-...
- pjmlp 1y ago
  It is still around, although only a few care about it.

Madetocomment 1y ago

It's available on on pixel since pixel 8