The last two major releases of macOS have brought rapid evolution in the protection of their system files. Before explaining what is happening in macOS 11 Big Sur, I’ll recap what has happened so far.

In macOS Mojave 10.14, macOS boots from a single APFS volume, in which sensitive system folders and files are mixed with those which users can write to. The main protections provided to the system come from classical Unix permissions with the addition of System Integrity Protection (SIP), software within macOS.

In Mojave, all malware has to do is exploit a vulnerability in SIP, gain elevated privileges, and it can do pretty well what it likes with system files.

Catalina 10.15 changes that by splitting the boot volume into two: the System and Data volumes, making up an APFS Volume Group. Immutable system files now reside on the System volume, which not only has complete protection by SIP, but is normally mounted read-only.

This makes it far tougher for malware, which not only has to get past SIP but to mount the System volume as writable before it can tamper with system files.

Although Big Sur uses the same protected System volume and APFS Volume Group as Catalina, it changes the way that volume is protected to make it an even greater challenge for those developing malicious software: welcome to the Signed System Volume (SSV).

Every file on Big Sur’s System volume now has a SHA-256 cryptographic hash which is stored in the file system metadata. When data is read from the SSV, its current hash is compared with the stored hash to verify that the file hasn’t been tampered with or damaged. Those familiar with my file integrity tools will recognise that this is essentially the same technique employed by them.

Further hashing is used in the file system metadata itself, from the deepest directories up to the root node, where it’s called the seal. This ensures those hashes cover the entire volume, its data and directory structure. The seal is verified each time your Mac starts up, by the boot loader before the kernel is loaded, and during installation and update of macOS system files. If verification fails, startup is halted and the user prompted to re-install macOS before proceeding.

Updates are also made more reliable through this mechanism: if they can’t be completed, the previous system is restored using its snapshot.

For the great majority of users, all this should be transparent. You install macOS updates just the same, and your Mac starts up just like it used to. You can have complete confidence in Big Sur that nothing has nobbled what’s on your System volume. The only time you’re likely to come up against the SSV is when using bootable macOS volumes by cloning or from a macOS installer. Whatever you use to do that needs to preserve all the hashes and seal, or the volume won’t be bootable. All good cloning software should cope with this just fine.

If you need to install a kernel extension (not one of the newer System Extensions, DriverKit extension, etc.), that is no longer built into the prelinked kernel which is used to boot your system, instead being built into /Library/KernelCollections/AuxiliaryKernelExtensions.kc. As that’s on the writable Data volume, there are no implications for the protection of the SSV. Further details on kernel extensions are here.

What definitely does get much more complex is altering anything on the SSV, because you can’t simply boot your Mac from a ‘live’ System volume any more: that will fail these new checks. Apple has extended the features of the csrutil command to support making changes to the SSV. In outline, you have to boot in Recovery Mode, use the command
csrutil authenticated-root disable
to turn cryptographic verification off, then mount the System volume and perform its modifications. To make that bootable again, you have to bless a new snapshot of the volume using a command such as
sudo bless --folder /[mountpath]/System/Library/CoreServices --bootefi --create-snapshot

You can then restart using the new snapshot as your System volume, and without SSV authentication.

In Catalina, making changes to the System volume isn’t something to embark on without very good reason. In Big Sur, it becomes a last resort.

Further reading

Mojave boot volume layout
Catalina boot volume layout
Apple’s Develop article

Thanks to Damien Sorresso for detailing the process of modifying the SSV, and to @afrojer in their comment below which clarifies what happens with third-party kernel extensions (corrected 1805 25 June 2020).