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!