For the whole of Mac OS X until Mojave, the system booted from its firmware into a single boot volume, containing a fairly traditional mixture of system and user files. As with most boot volumes, this made it difficult to protect system files that shouldn’t change between macOS updates, and to detect whether changes have occurred in them, whether by corruption or maliciously. Apple introduced System Integrity Protection (SIP) in 2015 (El Capitan) to try to address the first of those, but it has limited effectiveness and can’t detect changes at all.

When designing the architecture to be used in Apple silicon Macs, Apple decided that they should have a secure boot process, in which each stage hands over to code that has already been verified as intact and correct. This chain of verification starts in the Boot ROM, which verifies the next stage, the Low-Level Bootloader (LLB), before loading it, and that then proceeds to iBoot, which has the task of verifying the System.

For the smaller chunks of code and data that compose each part of the boot process before the kernel, it’s efficient to compute a hash of its code and compare that against what it should be, but that isn’t a good approach to verifying the 9 GB or so required for the system itself. To handle that, Apple chose to build a tree of hashes instead. Out at its leaves are individual files in the system, each hashed in a group to provide a set of intermediate hashes. Those in turn are hashed in groups, until at the top of the tree is a master hash of the hashes below it. That master hash is known as the seal, and is hashed again to produce a key for the whole system, its signature.

To verify the whole System volume at its top level, all that’s required is to ensure that its signature matches that set by Apple for that version of macOS. Then, as the volume is accessed, the system verifies the hashes further into the tree towards its leaves as necessary.

Because this integrity checking is also required for security, Apple chose to use cryptographic hashes rather than the checksums more commonly used in file systems. APFS already uses Fletcher 64 checksums for file system metadata, but those aren’t robust enough to protect against deliberate attack, and wouldn’t work as efficiently as a tree of hashes.

The final twist applied for the Signed System Volume used for the kernel boot process is that it’s turned into an immutable snapshot before the tree of hashes is built and stored in its metadata.

Another important feature of the System and Data volumes is their union using firmlinks, which effectively join their two directory trees at several points so they can be seen and accessed as if they were a single volume.

Thus, the boot volume group introduced in Big Sur is a far more complex beast than the previous single boot volume used in Mojave and earlier; Catalina acted as an intermediate in the process of migrating to this new architecture, in that it has the volume structure but the System volume is mounted read-only and not a mounted snapshot.

Making an identical copy of a single boot volume using ‘cloning’ isn’t a particularly difficult task, and many of us used to do this routinely. One neat cloning trick was to use this as a method of defragmenting free space: clone your boot volume to another disk, and clone it back again. However you try to do that with a new boot volume group, there are snags and problems. Currently, the only way you could do it is using the command tool asr, or an app like Carbon Copy Cloner or SuperDuper! that forms a wrapper for that command. If you want to know how to do that, this account is well worth reading before you make any decision.

asr has some magical capabilities, such as being able to copy a snapshot, many of which can’t be achieved any other way. It’s also prone to failure, in which case the only solution is to install a new copy of macOS.

That brings me back to the best solution: rather than trying to clone a boot volume group in Big Sur or later, isn’t it far simpler and more reliable simply to install macOS and migrate from the Data volume?

Finally, many of you ask when Apple is going to make cloning the boot volume group easier again. The answer, I believe, is never, and in the future even cloning using asr may well disappear altogether. It’s now almost four years since Apple released Catalina and started down the road to Secure Boot and the Signed System Volume. It’s hardly going to want to step back and throw all the benefits away. You should also consider other ways of creating identical systems, such as lightweight virtual machines, that can be cloned in an instant and don’t even take much free disk space.