Last Week on My Mac: How it took 6 months for M1 Macs to work properly

Last week, with the release of Big Sur 11.4, Apple finally addressed most of the problems users had been experiencing getting external boot disks to work properly with their M1 Macs. Today I’m going to look back over the last six months, since the first M1 models shipped, and ask what went wrong.

Being able to boot a Mac from an external disk is a fundamental feature on which many Mac users have relied since the release of Mac OS X and well before. It’s widely used by software engineers, for example, to enable a single Mac to be run using several versions of macOS, and with the imminent release of the first betas of macOS 12 will soon assume even greater importance. Some rely on it so that they can work in an identical environment across two or more different Macs. It has also been a mainstay for many system administrators and advanced users to maintain or repair Macs which have developed soft problems. It may not be the most popular configuration, but that doesn’t make it any less important.

Within a month of the first new M1 Macs being delivered to users, there were several reports of problems getting them to work with bootable external disks. Tim Standing of OWC reported some of these, and a few days later I described them here. At this stage, trying to create a bootable external disk often failed, with a variety of different problems, whether in macOS 11.0.1 or 11.1, which had been released on 14 December.

Just before Christmas, when still testing with 11.1, I discovered a way which appeared to work for some Thunderbolt 3 SSDs. I then revisited the problems with 11.2 and 11.2.1 and still couldn’t get all my test SSDs to work properly. As I wrote in my conclusion there:
“M1 Macs currently don’t work reliably with bootable external disks. Users who want to boot from an external disk would be wise not to buy an M1 model, until Apple has fixed these problems completely.”

A few days later, I discovered that SATA/USB-C disks worked better when connected to the USB-A port on my M1 Mac mini, but that some Thunderbolt 3 disks still wouldn’t update macOS using Software Update, and of course had no option to use a different type of port. I later revisited the problem of updating a working bootable external SSD, and concluded that “At present, trying to use external bootable disks with an M1 Mac is a nightmare.” In growing despair, I asked whether external boot disks might even be a thing of the past.

In fact, Apple had already stated unequivocally that external boot disks were intended to be supported by M1 Macs running Big Sur. Its Platform Security Guide states:
“If a user chooses to boot from external media, that operating system version must first be personalized using an authenticated reboot from recoveryOS. This reboot creates a LocalPolicy file on the internal drive that’s used to perform a trusted boot from the operating system stored on the external media.
This means the configuration of booting from external media is always explicitly enabled on a per operating system basis, and already requires user authorization, so no additional secure configuration is necessary.”

On 26 April, Apple released macOS 11.3, and at first I was encouraged, which led me to conclude that booting an older version of macOS was a matter of changing LocalPolicy for the external disk, which I elaborated here, completely incorrectly as it turns out.

By this time, with 11.3.1 installed on my M1 Macs, Apple had revised its Platform Security Guide, in which it defined the three levels of security for an M1 Mac:

  • Full Security: The system behaves like iOS and iPadOS, and allows only booting software which was known to be the latest that was available at install time.”
  • Reduced Security: […] This allows the system to run older versions of macOS. Because older versions of macOS inevitably have unpatched vulnerabilities, this security mode is described as Reduced. This is also the policy level required to support booting kernel extensions (kexts).”
  • Permissive Security: The system behaves like Reduced Security […], but it also tells iBoot that it should accept some boot objects being signed by the Secure Enclave with the same key used to sign the LocalPolicy. This policy level supports users that are building, signing, and booting their own custom XNU kernels.”

In practice I had found that, in macOS 11.3.1, all attempts to install an older version of Big Sur on an external SSD failed, and once the internal SSD had been updated to 11.3.1, it wasn’t even possible to update older versions of macOS on external SSDs. The only way to solve the latter was to downgrade the disk to Reduced Security. That behaviour didn’t appear consistent with the definition of Full Security, but could be one interpretation of Apple’s description of Reduced Security.

When Apple released Big Sur 11.4 update, nothing in its release notes indicated that any change had taken place in support for bootable external disks. Indeed, as far as I can tell, Apple hasn’t mentioned these problems, and anyone considering buying an M1 Mac would probably be completely unaware of their gross unreliability with bootable external disks.

It was a great surprise to discover that almost all these problems have been fixed in 11.4, and that in most cases external disks can now run older releases of Big Sur without downgrading security, or connecting a perfectly good SATA/USB-C disk to a USB-A port. Software Update and old installer apps which had previously been unreliable at best, and generally failed to work with external disks, suddenly work fine.

There’s an obvious explanation which I came across when looking at what had changed in the 11.4 update: a brand new kernel extension AppleVPBootPolicy.kext which is concerned with the management of LocalPolicy, which determines security level on boot disks. What’s also a little odd about that kernel extension is that its text refers to Aruba hardware, which appears to be Apple internal language for the A12Z SoC used in only one Apple Silicon Mac, the Developer Transition Kit (DTK), which isn’t supported by 11.4 and had to be returned to Apple by the end of February 2021.

Suspicions that these problems were the result of bugs in Big Sur’s updaters or installers therefore have little support. The evidence is that these problems were the result of bugs in managing and implementing LocalPolicy, which were fixed by that new extension, and other changes in macOS 11.4. In other words, M1 Macs didn’t work properly for a period of six months because their Secure Boot system was broken.

It’s possible that Apple wasn’t aware of this until early this year, but that appears most unlikely. Far more probable is that Apple knew full well for the whole period of six months that Secure Boot prevented external bootable disks from working properly. Over that period, when DTK systems were still out with developers, Apple re-engineered macOS to address these issues, notably in the AppleVPBootPolicy kernel extension.

Not only did Apple fail to warn the millions buying M1 Macs that their new computers couldn’t boot and run reliably from external disks, but when it updated its Platform Security Guide in February 2021, the account given there was an aspiration not reality.