So I'm working in understanding the Apple Silicon boot/OS provisioning process. This is all subject to change, but here are some takeaways according to my current understanding.

References:
https://support.apple.com/guide/deployment-reference-macos/startup-security-ior2b1833593/web

https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot

Apple Silicon devices have a, by default, tightly controlled boot process similar to iOS. The bootloader is also quite dumb and cannot actually boot from external media. Internal storage (the SSD) is tightly coupled to parts of the boot process.

This means that in order to set up an Apple Silicon device to boot arbitrary code, you first need to set it up to boot macOS, or at least install a working recovery mode.

In other words, if you wipe the entire disk, that's like wiping your UEFI firmware in a PC.

You won't brick the thing, because there is DFU mode, but you will have to download a recovery bundle from Apple and install it first; just like there's no Linux on a PC without the manufacturer UEFI firmware (unless it's one of the rare coreboot supported ones).

In addition, Apple has a mechanism they use to only allow recent versions of their software to be installed on devices, by requiring a "phone home" process when you install it.

This requirement can be disabled *after* you have a working install.

This makes sense; what Apple is doing is giving us advanced users a way to opt out of all of this, while making sure regular users cannot be compromised. The opt outs are stored on the SSD. So if you wipe your disk, Apple will treat your Mac like a secured device again.

One neat thing though, is that in fact these security settings are *per OS install*. This means that it should be entirely possible to dual-boot a *fully secure macOS* and Linux. That means you should be able to run iOS apps in macOS (which is disallowed without security).

This is like having an Android that can dual-boot the stock OS without OEM unlock and passing all SafetyNet checks, and also whatever custom OS you want without Gapps and anything else. Which is really cool.

So the takeaway here is: Apple have built a very clever secureboot process previously unseen in any kind of desktop computer. They make us go through hoops to boot Linux, but those hoops are there to protect normal users.

Once your Mac is set up with an OS install with permissive security, there is no phoning home or anything like that; that is just for from-scratch setups or if you need to reinstall.

It is up to us (i.e. Asahi Linux) to provide recovery mechanisms that allow you to fix a broken Linux install without having to depend on additional Apple software or do a full machine restore (and we will, don't worry).

In other words: Apple Silicon is like a Google Pixel device, but better. You need the factory OS to get to the "enable OEM unlock" toggle, and after that you're good.

As long as you only mess with the installed OS (system/data partitions), you can do whatever you want.

On Android there is a signed, verified boot chain, up until the OS kernel where unlocking is possible - exactly the same as on Apple Silicon.

Apple Silicon allows multiple installed OSes, and that boundary is slightly before the OS kernel (includes OS loader and some firmware).

If you truly wipe all storage on Android, you hard-brick the device (unless you can find private vendor tools to restore from a blank slate, if possible at all). On Apple Silicon you can always fix it with a documented process - but it does involve phoning home to Apple.

Apple Silicon Macs do have a separate NOR flash for core system firmware and manufacturing settings (think: serial numbers, certificates, calibration data, etc) - if you wipe *that* then you have to send the thing off to Apple to fix it. But there is no reason for us to touch NOR

I think that about sums things up for what to expect when setting up a Mac to run Asahi Linux.

The actual process is all going to be automated in a `curl | sh` style thing in macOS or Recovery Mode, so regular users won't have to care much about the details either.

By the way, we have to thank @XenoKovah, @NikolajSchlej, and everyone else involved for designing this process and making this entire thing possible. https://twitter.com/XenoKovah/status/1339914714055368704