>What good does that bring if Apple shuts down the project?
How could they do that? They could cease providing the facilities the project relies on in newer chips, but the existing chips, er, exist. They could stop making chips all together and go back to intel. It's not a useful hypothetical.
>Also, I don't believe Apple has no backdoors and such. They basically made it impossible to be root on your iPhone, so you don't think they have a almighty-super-superuser mode on their laptops that only they can use?
It's possible such a thing exists, of course, it's possible on intel, or AMD, or any ARM chips, or any chip at all. However such a back door, if discovered, would not be accessible only to them. It would have the same problem that all such backdoors have, in that if Apple can exploit it, others can exploit it. Apple very heavily relies on the claim that they have no such back door, and they have relied on this as a legal defence, and frankly it's hard to see how they would benefit from having such a back door. A chunk of their business model and legal liability protection depends on not having such a back door.
>Wishful thinking if you ask me.
If you say so, this is all about relative risk. However what reason might anyone have for thinking that any other platform, such as Intel with it's proprietary supervisor code with remote updatability, is more under the control of the user? There may be platforms that have a better security architecture that's more under the control of the user, but I can't think of any of the major ones that does. Which would you suggest?
> Apple very heavily relies on the claim that they have no such back door
And, at least in the case of their private cloud compute, they encourage third party audit of their claims and even provide a virtual research environment running an instance of their PCC on your mac.
The UK explicitly requesting a backdoor to iCloud's advanced data protection forcing Apple to pull the service instead also tells me their claims are legit.
It's certainly possible a backdoor exists in hardware instead, or elsewhere in the stack but given Apple's surprising relative openness for how they implement their privacy products & the research papers they put out I'm inclined to believe them for now. (I say relative because its not open source, which is the only way to be 100% certain, but their research papers are surprisingly in depth).
> How could they do that?
iBoot? Asahi needs iBoot to boot third-party volumes for Linux to run properly. Apple controls iBoot; if they burn an eFuse and disable third-party volumes in a "Security" update, Asahi cannot fight back.
You cannot boot macOS with an unsigned iBoot firmware, so writing your own bootloader isn't an option. If a fuse is burned, you also cannot downgrade to older firmwares. The entire system is designed to give Apple the ability to disable other OSes in a macOS update if they ever decided to.
iBoot firmware exists and is already in our hands.
Any manufacturer could put an eFuse in any of their hardware and lock it. No hardware can be proven not to have such exploits. That's the first point marcan makes in that post.
> Any manufacturer could put an eFuse in any of their hardware and lock it.
This is my point too, though. Do we trust Apple to not burn a hardware fuse if their community one-ups them? They've already done it on iPad and iPhone hardware when users find a boot ROM exploit. All that they'd need to do is push an update for "security" purposes, and then the new boot flow could refuse to boot into unsigned volumes or deny running unsigned bootloaders. There would be no way to downgrade.
This is basic ARM security architecture stuff, I'm a little shocked that people can't imagine how this type of lockout is possible. There are tons of commodity ARM boards that are effectively bricked and eFused to user-hostile security epochs.