[rtsil]

From the accompanying article:

> Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake.

This screams backdoor by some powerful actors.

[DannyBee]

This appears to be used to direct write cache for testing purposes. It's not an intentional backdoor.

It's more likely an insider leak of some private headers or something that gave someone the info necessary. Or Apple left too much stuff in the debug info.

It would not be the first time either has happened.

[seanhunter]

No info one way or another, and I am not a nation-state actor, but if I was and was intending to introduce a back door to some platform, I would ideally want there to be some plausible explanation of it as an innocent mistake so that if/when it eventually got discovered everyone would think: “oh boy someone accidentally left the debug build in for this one” or “oh someone needed a godmode for testing and they accidentally enabled it in production” or whatever, rather than it being right there obvious in the code with no ambiguity. If you’re operating against active adversaries it makes sense to work on the basis that your activities will one day be uncovered and therefore to prepare the cover story ahead of time.

Additionally if you think about it if you’re an insider trying to subvert some system all your changes would still need to go through PR etc so it’s going to be pretty difficult to get some egregious backdoor through review vs figuring out a way to “accidentally” link in a test/debug version of some lib into production or something similar.

[DannyBee]

This would make sense if it was a one-off.

But apple has hundreds of debug registers. They have >1000 apple-specific MSR registers in the M3, which can be used to bypass/test lots of things, not just this, if you have enough permissions.

They were historically not locked down for the most part, just undocumented.

Apple has MSR lockdown registers that let them lock down access to MSR's (which only makes it harder, you can unlock access again later, but it means you have to be able to write the lock MSR to unlock them), and the latest kernels now lockdown most MSR's.

XNU also even has code to inject AMCC/DCS/ECC errors for testing.

Almost all of these can be seen from the KDK, and it's been that way for years.

This specific thing being a backdoor is totally implausible as a result. It's almost certainly not the only test mechanism that could be exploited due to some bug.

The CPU registers are MMIO accessible, like the GPU ones, but protected through various mechanisms that the GPU ones are not, by design (the GPU has no IOMMU).

It is much more likely they paid an insider for access to the GPU register names/info, or found it through a leak, and then started trying to see what they could do with the info, than it is that the entire thing, top to bottom, was an intentional backdoor.

[seanhunter]

That makes sense. Thanks for taking the time to explain.

[DannyBee]

I'll go a little further on why i think it's not a backdoor.

If you look at the debug info in the Kernel dev kits, you can see the internal SDK (which has existed forever - i had access to it 2 decades ago when i was working on compilers at IBM, for apple) has chip/register info in it:

    DW_AT_decl_file             0x00000014 /AppleInternal/Library/BuildRoots/8a51e4ad-7e8b-11ee-8cd8-2a65a1af8551/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.Internal.sdk/usr/local/include/EmbeddedHeaders/soc/module/dart_v14.h

    DW_AT_decl_file             0x00000017 /AppleInternal/Library/BuildRoots/8a51e4ad-7e8b-11ee-8cd8-2a65a1af8551/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.Internal.sdk/usr/local/include/EmbeddedHeaders/soc/module/p_acc0_v5.h

Just some examples. The first one is a header file containing the register names/structures/flags etc for the DART. The second is for recent p-cores. etc

Depending on what the kernel uses, sometimes they accidentally leak most of the data (more than once).

So for example, the current XNU debug info leaks the register bits/structure of the hid18 register (a p-core register):

https://gist.github.com/dberlin/ec277fc61c33419e658a17f743e1...

(I put this in a GIST because i am too lazy to try to get the formatting right in-comment)

So you can see the bits of HID18 and what they mean, just from the debug info.

Now, current XNU dumps contain info on 2-3 registers like this out of the thousand+.

But, the header files contain all the data, presumably, on CPU, GPU, DART, etc.

They have also leaked much more before.

Regardless, it is much more likely to me that someone got a recent internal SDK (which again, was at least shared with partners at various points in time), went looking through the header files, and then started testing things out, than it is to me that they engineered a backdoor from scratch into the GPU.

[philistine]

If you wanted to backdoor Apple's chipset, you wouldn't build one that could be closed through software without any impact whatsoever.