upvote
> 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).

reply
> 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.

reply
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.

reply
> 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.

reply