The common feature with these embedded ARM chipsets is that a faulty kernel can very much hardbrick your machine. There's nothing like the amount of failsafes you get with ordinary PC-compatible hardware. I wouldn't want to rely on any promise that "installing a custom kernel won't void your warranty" - in practice, it very much will if you don't know what you're doing.
You're assuming Apple's ARM chipsets are like other embedded ARM chipsets. They aren't. Things are much cleaner and quite well designed.
Storage-wise, you can't brick the machine by wiping NVMe. You can always recover via DFU mode, which you can also use from another Linux machine by using idevicerestore (no need for macOS). This is very much unlike your typical Android phone, which is indeed a flimsy mess that will brick itself at the slightest touch of the wrong partition in eMMC.
Hardware-wise, there's the usual "you can technically do ugly things with I/O pins", but in practice that's quite unlikely to cause damage. The lowest level, dangerous things are handled by SMC, not the main OS. We barely have to deal with any of that. And this is a thing on PCs too, just read your chipset's user manual and you'll find out the registers to flip random I/O pins.
Firmware-wise, I do know of one way of causing damage to these machines that cannot be recovered by the user: wiping NOR Flash. This isn't because it'll make DFU unusable, but rather because it contains things like system identity information and calibration data that only Apple can put back properly. But again, this isn't much different on PCs; you can brick a PC by wiping the NOR Flash from your OS too. In fact there have been BIOSes so broken that you can brick them by doing a `rm -rf /`, which descends into efivars and the UEFI implementation crashes when it finds no EFI variables.
In order to avoid the NOR Flash bricking risk, I do not intend to instantiate the NOR device in our device tree at all by default. I do not believe we need it for regular operation. Flash memories have specific unlock sequences for writes/erases, so there is practically zero risk that a crazy random bug (i.e. scribbling over random I/O memory) could trigger such an operation, and without the NOR driver bound, the code that actually knows how to cause damage will never run.
For what it's worth, I have quite some experience not bricking people's machines, even when dealing with unofficial exploits/hacks/jailbreaks. To my knowledge, not a single user out of the probably >10m people running The Homebrew Channel / BootMii on their Wii, which I helped develop, has bricked their system due to a problem traceable to our software. Nintendo has a much worse track record :-)
> system identity information and calibration data that only Apple can put back properly
Ha. This reminds me of a Motorola Linux phone I bricked as a kid by trying to write a package manager in C shell (lol) which inevitably led to rm -rf / being executed which wiped a unique per-device security partition required for the boot process.
Why did Apple make the same choice of putting critical data onto an OS-writable flash chip? Chromebooks do it right – everything critical lives in the Security Chip's own on-chip flash, and the list of commands it would take from the host system is very limited by default (most things are only available to the debug cable).
You might be able to restore the NOR with 'Apple Configurator 2', which seems to be a public version of an internal tool, though it's limited to taking an otherwise unbootable machine to a fully-installed-OS machine.
Plug the bricked machine into another Mac using a TB3 cable in a particular slot (they tell you which) and follow the instructions. Worked for me.
As far as I know, fully wiping it is recoverable, but involves putting the Mac into device firmware update mode, and then recovering from another machine.
AIUI if you actually wipe NOR flash entirely, DFU mode won't save you, because the Mac won't even know who it is (MAC addresses, serial number, etc.).
However, I can't claim to have tried it, so there may well be additional safeguards. I'm just not particularly interested in risking it for our users either way :)
