New Memory Integrity Enforcement CPU extensions in A19/A19 Pro

[Nycturne]

I meant the memory location of where the tag is stored. It’s a fairly contrived technical topic and I have a feeling that there are multiple conversations happening in parallel, not necessarily about the same thing

For sure there's a couple threads in this topic, but I'm following those pretty well. The reason I keep hammering on this is more that you brought it up as a means of making things more secure, and I am trying to figure out what it is that I'm missing.

Because ultimately hashing leaves the tag's storage address predictable. It has to be deterministic to be useful. So now you have a hash algorithm as your "secret", which once known means I can lookup any address as if hashing wasn't used. I can pile salt on top of that, which then means I need to know where the salt is stored (which if is in the process, an attacker could extract). Salt + hash might be enough to make it worth it if the pages containing these tables need to be readable by user land processes. But much like say, the TLB, I could make it such that the CPU's buffer is not readable, and instead the kernel is required to read memory into the CPU buffer on an interrupt when there's a cache miss at the CPU layer. So at least in principle, an attacker that is trying to attack a user process can't just read the tables anyway, meaning hashing and salting is mostly an exercise to stop kernel-level attacks, which starts getting to the point where MTE won't really protect you anyways, since I can re-write the tables, and intentionally trigger a fault that will let me read them into the CPU's buffer.

And all this seems somewhat moot, as it looks like there's a speculative execution attack on MTE as implemented in Cortex designs which do tag checking asynchronously: https://www.theregister.com/2024/06/18/arm_memory_tag_extensions_leak/

 

[leman]

For sure there's a couple threads in this topic, but I'm following those pretty well. The reason I keep hammering on this is more that you brought it up as a means of making things more secure, and I am trying to figure out what it is that I'm missing.

Because ultimately hashing leaves the tag's storage address predictable. It has to be deterministic to be useful. So now you have a hash algorithm as your "secret", which once known means I can lookup any address as if hashing wasn't used. I can pile salt on top of that, which then means I need to know where the salt is stored (which if is in the process, an attacker could extract). Salt + hash might be enough to make it worth it if the pages containing these tables need to be readable by user land processes. But much like say, the TLB, I could make it such that the CPU's buffer is not readable, and instead the kernel is required to read memory into the CPU buffer on an interrupt when there's a cache miss at the CPU layer. So at least in principle, an attacker that is trying to attack a user process can't just read the tables anyway, meaning hashing and salting is mostly an exercise to stop kernel-level attacks, which starts getting to the point where MTE won't really protect you anyways, since I can re-write the tables, and intentionally trigger a fault that will let me read them into the CPU's buffer.

This makes sense to me, thanks!

 

[Jimmyjames]

There is now a video from the Hexcon security conference where head of security at Apple, Ivan Krstić, discusses MIE.

 

[Lunaticum]

Wow, yeah, that’s pretty impressive! Half a decade of work shows how serious Apple is about memory safety. Always-on protection like that could really make a difference for security.

 

[Nycturne]

Wow, yeah, that’s pretty impressive! Half a decade of work shows how serious Apple is about memory safety. Always-on protection like that could really make a difference for security.

I’d be more surprised if there wasn’t this level of work involved. Especially after seeing what they did to migrate to a sealed system boot volume. I do really appreciate some of their methodology here. One thing that stuck out is that they have a bunch of processes in "telemetry only mode" when it comes to MIE. So they can verify their assumptions with a large user pool before turning it on and breaking a bunch of folks. One of the better uses of telemetry in cutting edge features I’ve seen in a while.

This makes sense to me, thanks!

Interestingly, the talk does cover this particular side-topic. It looks like tag tables are part of the purview of the SPTM, so they are getting heightened isolation and scrutiny similar to other sensitive kernel-level data related to memory. After reading about some of the exploits already present on other MIE implementations, and how Apple spent time mitigating them here, I feel pretty confident saying that Apple has the most robust MIE implementation in the industry right now. And it’s not even close.