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 …
-
Show this thread
-
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.
1 reply 17 retweets 67 likesShow this thread -
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.
1 reply 3 retweets 31 likesShow this thread -
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).
1 reply 2 retweets 27 likesShow this thread -
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.
1 reply 4 retweets 22 likesShow this thread -
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.
1 reply 15 retweets 49 likesShow this thread -
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).
4 replies 9 retweets 56 likesShow this thread -
Replying to @marcan42
oh huuuuuuh, where's that stored? does that mean you can just create a partition (on the internal storage), stick a Mach-O and permissive security settings on it, sign it all with a per-machine key (where does that live anyway?), and boot from it?
1 reply 0 retweets 1 like -
the boot policies for each volume are located in a special subvolume in the (global) iBoot system container partition, the per-machine key likely lives inside the SEP or the encrypted SEP storage (another iBoot system container subvolume), afaics
2 replies 0 retweets 2 likes
The partition right now at least needs copies of iBoot/etc, and I got it to "boot" from such a crafted partition (that was the screenshot earlier), but the blocker right now is that bputil wants login creds to downgrade security, and this ain't no macOS with login creds.
-
-
It's not yet clear is there is a way to provision all this without going through macOS, given the current security model implementation. We will see.
1 reply 0 retweets 1 like -
Replying to @marcan42 @dev_console
so it sounds like there's a flow to replace macOS with something else, but not to directly create a new non-macOS partition? or do we expect bputil under recovery OS to be able to set/sign policy for a selected other partition?
2 replies 0 retweets 0 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.