alt Hacker NewsThis is not exactly correct. They wouldn’t need to emulate SPTM, since SPTM is already running. And to be very correct, SPTM is a “process” running in a separate privilege level to the regular privilege levels found on arm processors. The reason it’s a pain is because pre M4 the bootloader gave you complete control over the CPU, including the Apple-exclusive extensions like GLx, the special privilege levels e.g. SPTM is running at. Since M4 the bootloader handles that, so asahi team has to either cope with being dropped after GL is already initialized and locked down, or running in a mode with all of Apple extensions disabled. So it’s not a problem for running Linux, but it’s a problem for running macOS with a thin abstraction layer to intercept talking with devices like the GPU, which made reverse engineering for them significantly easier.
Afaik this isn’t quite correct either. From what I could gather from the CCC talk and forum posts:
The Apple specific instructions to talk to the SPTM are only usable in the GL2 privilege level, not EL2 where you end up after booting non-Apple code.
The problem is the macOS kernel uses these custom instructions to manage its own page table mappings, and when being virtualized in EL2 it just crashes since these instructions are now invalid.
The solution is indeed to emulate the SPTM interface and instructions just enough for macOS to not crash, that way it can be virtualized for reverse engineering. The emulated SPTM could just pass through the mappings, ignoring all of the security checks the real one would normally do.
I was able to find quite a bit of existing SPTM analysis online (I believe from iOS security research) so this issue isn’t insurmountable by any means.