> There is a vulnerability in the SoCs that I discovered and reported where cache snooping bypasses CTRR at the AMCC level. You can "write" to read only memory ranges and, as long as those writes remain in snoopable cache, they are effective even though AMCC will block them and panic when they are written back. I didn't get any money for that one because the way I exploited it didn't apply to normal macOS (I used it to patch DCP code from m1n1), but now a nation state figured out how to use it for a real exploit chain. "Whoops".

Oooff

Is this like "micro-code patchable" or hard no?

If it's the cache hardware, probably not. That's not programmable, you get whatever configuration the designers baked in, and that's it. Though as described you could likely work around this by changing the cache mode to write-through, albeit at a fairly severe performance penalty for the affected accesses.

Apple supports locking down MSR registers for the CPU's.

I would not be surprised if they added the same functionality to the GPU registers.

There are a tremendous number of debug registers in these things.

Apple has >1000 apple-specific MSR's for the CPUs, mostly used for debugging/testing

However, unlike the GPU, they are protected by more than just PPL. But you can use them from m1n1/etc and see what they do.

It is not surprising to find they have the same for GPU processor, the difference is that the GPU has no IOMMU, so forgetting to map a page that contains the register shadows is exploitable in a way that it's not for the CPU

What's PPL?

Edit: Page Protection Layer (https://googleprojectzero.blogspot.com/2020/07/the-core-of-a...)

No, this is all Apple hardware. Other SOCs often have equivalent features and might plausibly make the same mistake (which per the Hector Martin toot is effectively "the write back cache doesn't check security access control so you can stuff data into it to be snooped by other devices"). But this bug is Apple-only.

This only works at all because there is no IOMMU for the GPU. So they'd also have to decide not to do that as well.

Yeah, but lots and lots of hardware lives across a bus without an IOMMU. Until very recently, that was the natural state of things. To me what's notable here is that they have a snoopable cache across a security boundary, where you can get the IO device to read arbitrary data you stuffed in from the CPU, when the CPU can't actually touch the underlying storage being cached!

The bypass is Apple-specific… which it must be, because the security feature being bypassed, CTRR, is itself Apple-specific. I don’t think Android phones or Raspberry Pi even have any equivalent.

So the problem is unified memory? CPU and GPU uses the same RAM but the GPU doesn’t have proper MMU protections in place, which lets an attacker write to RAM it shouldn’t be allowed to by doing it through the GPU instead of the CPU?

GPUs doing DMA is a problem whether you have unified memory or not. This is why IOMMU exists.

But in more traditional systems the GPU would use its own physical RAM, which should at least make it isolated?

It still uses DMA for communication with the host, it's just over PCIe instead.

That thread is a more interesting read than the blog post.

> $150k bounty

That’s one heck of a way to fund Asahi

Recent XNU in the KDK also have code to do injection of AMCC errors, ECC errors, and DCS errors for testing purposes.

I bet someone figured you could do the same for the GPU.