This 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.
From our knowing how it works [0] it’s just a mechanism for the kernel to give up some privileges and add extra security checks when modifying page tables. Sounds easy to emulate to me: just don’t do the checks and modify the page tables directly. Do you have some reason to believe it can’t be emulated?
If for some reason it’s difficult, the relevant kernel code could also be hooked or patched.
You can (and should) watch all of https://www.youtube.com/watch?v=BLGFriOKz6U&t=1993s for the details about how iCloud is protected by HSMs and rate limits to understand why you’re wrong, but especially the time-linked section… instead of spreading FUD about something you know nothing about.
As of macOS Tahoe, the FileVault key you (optionally) escrow with Apple is stored in the iCloud Keychain, which is cryptographically secured by HSM-backed, rate-limited protections.
Unbreakable phones are coming. We’ll have to decide who controls the cockpit: The captain? Or the cabin?
The security in iOS is not to designed make you safer, in the same way that cockpit security doesn't protect economy class from rogue pilots or business-class terrorists. Apple made this decision years ago, they're right there in Slide 5 of the Snowden PRISM disclosure. Today, Tim stands tall next to POTUS. Any preconceived principle that Apple might have once clung to is forfeit next to their financial reliance on American protectionism: https://www.cnbc.com/2025/09/05/trump-threatens-trade-probe-...
Mailbox encryption is near pointless since at the least it needs to be encrypted at both ends not to mention relays.
For email each individual message should be encrypted if you want any confidentiality and even then the meta data is in the clear.
And this is because in order to send or receive an email the provider needs to access it. If they put it into a box later on to which they do not hold the key that is just security theater at that point.
A lot has changed since then and it is common knowledge that Apple regularly give government agencies access to their systems and hides it from the public until a whistleblower leaks it.
In a statement, Apple said that Wyden's letter gave them the opening they needed to share more details with the public about how governments monitored push notifications.
"In this case, the federal government prohibited us from sharing any information," the company said in a statement. "Now that this method has become public we are updating our transparency reporting to detail these kinds of requests."
I see this argument repeated every single time someone tries to defend Fahrenheit.
if "room temperature" was smack in the middle, at 50 degF, you might have a point.
but no, it's pure post-hoc rationalization.
being naked at 0 degF will kill you. being naked at 100 degF will (usually) not. they're not remotely equivalent.
instead, think of it this way - human beings are mostly water, and 0 to 100 degC is "percentage of the way from water's freezing point to boiling point".
room temperature is "about 20% of the way to boiling". 40% or higher starts to cause our bodies to overheat. a typical sauna will be somewhere between 50 and 70% of the way.
Close enough for government work, actually. And it's not just flesh. Lots of things behave approximately like water, which is handy for all sorts of back-of-envelope estimates.
reply