One of the worst longstanding problems with macOS has been its unreliability, and by that I’m not referring to bugs, but the fact that until a year ago you never knew whether your Mac’s system was intact or had become corrupted. That changed with the release of Big Sur, and continues to improve. This article explains what has happened and how it affects the way that you use macOS. This is particularly aimed at those who have been running older versions of macOS, and are finding themselves suddenly dealing with Monterey, for example on a new M1 Pro/Max MacBook Pro.

A robust file system

To understand what has happened, consider the changes made in Mac OS and macOS from Sierra. First, High Sierra introduced a new file system, APFS. Its predecessor HFS+ had served long and well, and is known to have several longstanding flaws. One of the most significant advances in APFS is to make changes to the file system more reliable using copy-on-write. Whereas HFS+ needs journalling and frequent maintenance, and even then is often left with minor errors in the file system, APFS is designed to be thoroughly robust.

In Mojave, macOS has reached its peak booting from a single volume, with a layout broadly similar to many versions of Unix.

Many of the system folders within this are protected by SIP, but all are within a common file system, are installed and updated together, and there’s no checking of integrity. As with previous versions, one of the most popular solutions to a wide range of problems has been to re-install the system. This often works well, as there’s precious little to prevent system files from becoming corrupted, and no means of telling whether they have been.

The boot volume group

Catalina brought the intermediate step in addressing those shortcomings, by splitting the boot volume into two, another new feature of APFS. One, which only changes in macOS updates and installs, became the System volume, and is mounted read-only; the other, the Data volume, then contains all the writeable files, including user Home folders, and those parts of the system which can change between updates.

Other changes were taking place in our Macs. While it was just possible to install Mojave on and boot from HFS+ on a rotating hard disk, by Catalina you have to boot from APFS, and that in turn requires an SSD. It’s still possible to boot Big Sur and even Monterey from a hard disk, but that’s not through choice. Apart from speed, SSDs brought additional benefits, of increased reliability and their lack of ill-effects from fragmentation. Macs supplied with internal SSDs also gained Secure Boot, thanks to their T2 chips, and most recently with the integral Secure Boot of the M1 series chips. From here on, I’ll refer to Macs with Secure Boot; Intel Macs without T2 chips have more limited benefits.

The Sealed System Volume

Big Sur completed the transformation. Catalina’s separate System volume became a sealed snapshot, protecting the system files even more, and that’s what Monterey uses too.

In this simplified diagram of the boot volume group in Monterey, folders stored on the System volume are shown in red, and those on the Data volume in blue. This layout segregates the contents of the system into files which don’t change, except in a macOS update, and everything else which does. My favourite example of this is what used to be the single top-level Applications folder, containing a mixture of bundled apps which are installed with macOS, and our own apps which we download from the App Store and Internet.

In Monterey, what appears in the Finder to be a single folder with the same contents actually consists of two folders: one on the System volume contains the apps installed as part of macOS, the other on the Data volume contains those we install. Those two folders are firmlinked together and the Finder creates the illusion that it’s just a single folder.

Not only are these immutable system files stored on their own System volume, but your Mac no longer boots from that as a conventional volume: it’s actually a snapshot, another modernising feature of APFS which has made this all possible. Perhaps the best way to see how this works is to consider what happens when macOS is installed or updated, in Big Sur or Monterey.

Early during installation, the Data volume is unmounted, ensuring that its contents are protected from any ill-effects of failed installation. The System volume is mounted for writing and SIP disabled, then the contents of the update are written to it, just as would happen in Mojave. With all the updated system files in place, a SHA-256 hash is then calculated for every file in the system, and stored in its file system metadata. Each group of hashes is then hashed again, and so on until there’s one top-level hash, known as the Seal.

If a single bit in any of those system files changes, that changes that file’s hash, which no longer matches its set value. That error propagates right up the tree, and the Seal itself no longer matches that laid down by Apple for that version of macOS. When that happens, the Seal is broken, and that Mac can no longer boot from that copy of macOS, so enters Recovery mode for the user to re-install macOS. The Seal therefore guarantees the integrity of every single bit in every single file on the System volume.

Rather than booting from that sealed System volume, the installer then makes a snapshot of the System volume, which contains all the hashes and the Seal itself. After enabling SIP, the System volume is unmounted, and macOS boots from that snapshot. Snapshots are immutable, in that even macOS can’t change them, a protection far stronger than mounting the System volume read-only as in Catalina. The Data volume is mounted, and any changes made to it are completed for that boot.

By the time we’ve got to Monterey, for models with Secure Boot:

• Your Mac will only boot from a snapshot of the System volume which can’t be changed in any way.
• Your Mac will only boot from a sealed system, which is identical to the last bit with that prescribed by Apple.
• Nothing apart from a macOS installer/updater can change the System volume.
• For much or all of the macOS update/install process, the Data volume is unmounted and can’t be affected by problems occurring during the update/install.
• All this is happening on an SSD, with its high reliability.
• The file system used is APFS, with its high robustness.

This doesn’t prevent users from doing radical things like building their own kernel, though. Secure Boot can be disabled, and M1 series Macs offer three different settings in their Startup Security Utility to cater for pretty well everyone.

How, then, can you check whether your installation of macOS is factory-fresh, or has become damaged or corrupted? Simply restart your Mac: if the Seal is broken, you should very quickly know about it, at least on Macs with Secure Boot when that is fully enabled.

Limits

The Sealed System Volume (SSV) addresses the integrity of those system components on the System volume, but doesn’t currently extend its cover to system components stored on the Data volume, nor to user files there. As Mac malware doesn’t normally try to tamper with what’s now on the System volume, you can still get a severe bout of malware without Secure Boot providing any protection. So too can key files stored on the Data volume become damaged or corrupted, or could be encrypted in a ransomware attack (should Mac ransomware appear again).

Another serious problem are user-installed kernel extensions, which aren’t part of the System, but which are given access to the innermost citadel of kernel space. That not only makes them a liability in terms of security, but makes it all too common for them to cause kernel panics. That’s why developers are moving quickly away from kernel extensions to system extensions, which run in user space instead. Before an M1 series Mac can load a third-party kernel extension, it has to be set to run at reduced security and you must explicitly enable their use.

Practical importance

If your Mac, running Big Sur or Monterey with Secure Boot enabled, boots normally, then its System volume is in perfect condition. Whatever might be wrong with it, re-installing the System volume isn’t likely to fix it.

At the end of a macOS update or install, if your Mac boots normally with Secure Boot enabled, then its System volume is in perfect condition. If the install fails, your best course is to enter Recovery mode and there re-install macOS. If that’s successful, you can have confidence in the integrity of the installed System again.

Although it may still be possible to ‘clone’ a System volume, the best and most reliable way to install Big Sur or Monterey on any disk is to use Apple’s full installer app, as that ensures that the boot volume group is created correctly, with firmlinks between System and Data volumes.

Secure Boot and the Sealed System Volume protect the System, not Data, volume. Keeping macOS up to date is the single most important way to protect your Mac overall.

Don’t install third-party kernel extensions if you can avoid it. Look for updated software which replaces them with system extensions.