How External Bootable Disks Work With Apple Silicon Macs
Unlike Intel Macs (including those with T2 chips), all Apple silicon Macs always start their boot process from their internal SSD, even when they are set to start up from a bootable external disk. This ensures the security and integrity of that process and prevents an attacker from starting that Mac up without credentials.
However, this is a problem if the internal SSD isn’t working properly, as happened to me.
In addition to normal requirements for a macOS installation on an external disk to be able to boot a Mac, ownership of the boot volume group on that disk is required. This is normally performed when installing macOS on that disk, as explained here, and results in the ownership of that boot volume group by an authorised user of that Mac. This is incorporated into a LocalPolicy that is saved to the internal SSD of that Mac.
[…]
To accommodate the more advanced Secure Boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.
[…]
Because restoring in DFU mode erases the whole of the internal SSD, it also blows away all saved LocalPolicy for that Mac. Following the restore process, any bootable external disk used with that Mac will need to have its ownership re-established so that a new LocalPolicy can be created for it.
It’s a common misunderstanding that trying to change Boot Security in Startup Security Utility can help solve Apple silicon boot problems, but if anything it only complicates them. Almost the only good reason for reducing boot security of an Apple silicon bootable system is when third-party kernel extensions are required. Otherwise don’t tamper with Startup Security Utility, as it will only confuse, as we’ll see later.
[…]
One important functional difference, which remains relevant to Big Sur boot disks, is that Apple silicon Macs don’t use the paired Recovery volume as their primary Recovery system: booting an Apple silicon Mac running Big Sur into Recovery should instead use the Recovery system installed in their internal SSD, in the Apple_APFS_Recovery partition. In subsequent versions of macOS, that’s used instead for secondary or Fallback Recovery. Thus Big Sur can be a problem when it comes to Recovery, and for this reason is best avoided on Apple silicon Macs. If it’s essential to install a copy of Big Sur, then be prepared for problems with Recovery mode.
[…]
Although APFS should be backward compatible, making it relatively safe to make changes to an older version of APFS from a newer system, forward compatibility is more limited. Using older versions of Disk Utility or tools like
fsckon newer versions of APFS risks errors, failure and at worst damage. The Appendix at the end of this article summarises version numbering in APFS and major changes to beware of.
Previously:
- Windows 11 Install to Require Internet and Microsoft Account
- Error 702 Installing macOS on an External Drive
- A Short History of Recovery in macOS
- How Recovery Works on M1 Series Macs
- Owner Accounts on M1 Macs
- Booting an M1 Mac From an External Disk
4 Comments RSS · Twitter · Mastodon
I suspect Howard and several devs at Apple and a couple Mac backup shops, are the only people on Earth who understand how to reliably keep disks bootable on new Macs.
Aside from all the other things about new Macs that I dislike, Apple's post-Steve philosophy for Target Mode and Bootable volumes is why I gave up on the Mac as my 'daily driver'.
Fantastic if other people feel the additional security is worth it for them. Personally, to work like this - with my setup tethered so tightly to a particular CPU - would feel precarious. I want the peace that comes with knowing I always have a backup I can revert to in case of hardware failure.
“This ensures the security and integrity of that process and prevents an attacker from starting that Mac up without credentials.”
Sure, but so does encasing the Mac in concrete—just depends how committed you are to security.
@Matthew Yeah, I don’t really understand what scenario it’s even protecting against. They already have ways to prevent access to the Mac’s data and to prevent rogue code from being added to an existing installation. Do I really care if someone has physical access to my Mac and they use it to set up a totally separate system booted from an external drive?
The disaster that is booting and permissions on an Apple Silicon mac is one of the main reasons I don't want one. I need one for work, however, and I've lost days of my life struggling to deal with getting it booting properly, especially on an external drive, or dealing with an administrator or root account still not having permissions to do certain essential things. There are so many things that can go wrong, and they all trigger weird inscrutable errors that there's no way to fix, unless you're one of the five people in the world who actually understand this, or someone on the internet just happened to post about the exact issue you're having and also just happened to come across the solution.
One of the things I loved about my earlier Intel (and PPC) macs is that I could just plug in an external drive and boot from it! It was so flexible and easy.
And who needs all this "security"? My threat model certainly doesn't require this. Hell, if my mac is stolen then my data is still protected six ways from Sunday. That was true with my Mac from ten years ago that didn't have secure enclave or T2 chip or any of this garbage -- all it needed was an encrypted drive. No one was going to break through that.
The only thing this is protecting me from is being confident I can boot or use my own computer the way I want, or make backups of this data the way I want. That is to say, it's an anti-feature. It'd be an anti-feature even if it *worked correctly*, which it often doesn't.
I've beaten this drum before and I'm going to do it again, but this is probably not a feature for me, but for Apple, because it lets *them* control how I use my own computer.
