Apple silicon Macs are the first Apple computers to feature fully secure boot processes as one of their fundamental design goals. Although similar in some ways to those in Apple’s devices and in Intel Macs with T2 chips, there are substantial differences. Unlike T2 Macs, secure Boot in Apple silicon is maintained even when starting up from external storage, a feature completely unsupported by devices. Non-standard configurations are also available to give greater flexibility with reduced security modes, which are absent from devices. This article explains how to manage Secure Boot on Apple silicon Macs.

Full Security

By default, Apple silicon Macs start up in Full Security, the mode recommended by Apple for normal use. That requires:

• Following pre-boot stages, a Signed System Volume (SSV) is loaded from its snapshot, with its seal intact and signature verified.
• The only kernel extensions loaded during boot are those supplied by Apple in macOS. No third-party kernel extensions can be loaded.
• System Integrity Protection (SIP) is fully enabled.

Because they run outside the privileged space of the kernel and its extensions, third-party system extensions and their relatives can be loaded and used fully.

Booting in Full Security applies full control and verification of all components from the Boot ROM, through the Low-Level Bootloader (LLB) and iBoot ‘firmware’, to the kernel and its extensions in the SSV. If any part of that sequence fails to verify, the boot process is halted and, depending on where the failure has occured, the Mac is either put into DFU or Recovery mode for the user to address the problem. This not only ensures robust security throughout, but it also guards against potential conflicts such as those arising with third-party kernel extensions, and unintentional corruption of any component.

Changing security

Control over boot security is applied using Startup Security Utility when booted in paired Recovery (except in Big Sur, as explained below). Access this by starting the Mac up into normal paired Recovery with a single long hold of the Power button. When the first screen has loaded, click the Options button, then from the Utilities menu select the Startup Security Utility command.

You will then be prompted to select the boot volume group whose security policy will be set. Note that in macOS 12.0.1 and later this must be the same as that for the paired Recovery being used.

By default that will already be in Full Security. Set the new policy as explained below, and click the OK button. To apply that policy, select the Restart command to exit Recovery and start up in normal user mode.

Startup Security Utility changes the LocalPolicy settings for that boot volume group; those are stored in the iSCPreboot volume on the hidden Apple_APFS_ISC container on the internal SSD of that Mac. Full details of LocalPolicy are given in Apple’s Platform Security Guide, and explained here.

Big Sur is a notable exception to the requirement to change security settings in the paired Recovery volume: it doesn’t have a paired Recovery volume, but boots into Recovery from a hidden container on its internal SSD, from where Startup Security Utility controls security settings for all mounted boot volume groups.

Fallback Recovery (frOS) is unable to change LocalPolicy, thus Startup Security Utility is unavailable when booted in frOS, its most distinctive feature.

Although the bputil command tool gives access to security settings, its use to modify them is hazardous, and shouldn’t be attempted unless you know what you’re doing and are prepared to have to restore that Mac in DFU mode. It is, though, sometimes useful as an aid to solving problems with LocalPolicy settings, as explained here.

Reduced Security

When reducing security settings, the only other option available is Reduced Security, which forms the gateway to Permissive Security as well. There are two other common reasons for selecting Reduced Security, though: to enable the loading of third-party kernel extensions, and to run older versions of macOS.

To enable the loading of third-party kernel extensions, Reduced Security must be set, and the upper checkbox ticked. Once this has been applied by a restart, installation and loading of the kernel extension can proceed using its installer and Privacy & Security settings. That doesn’t enable loading of the kext on demand, as in the past, as it has to be merged into a signed Auxiliary Kernel Collection, from where it can loaded during startup.

Although Apple states that Reduced Security is required to run older versions of macOS, that doesn’t appear to be required at present. Reduced Security differs from Full Security in that LLB and iBoot trust ‘global’ signatures that are bundled with macOS rather than using personalised signatures for iBoot and beyond. For many, this may appear to be an insignificant reduction compared with Full Security, although it does add the risks of loading third-party kexts when used for that purpose.

Permissive Security

Startup Security Utility doesn’t offer Permissive Security as an option until Reduced Security has been selected and an action has been taken to downgrade that to Permissive Security. The most likely reason for doing this is to partially or completely disable SIP using csrutil, and once that has been performed this third setting is shown in Startup Security Utility.

Just as with Reduced Security, this offers two further options in checkboxes, including that to enable the loading of third-party kernel extensions.

The main reason for using Permissive Security is to reduce SIP settings, and I have recently provided a guide to the controls available in csrutil. The normal sequence for changing those is to start up in paired Recovery, open Startup Security Utility, set that to Reduced Security and click on the OK button. Following that, open Terminal, run the appropriate csrutil command, then restart the Mac, which will automatically be in Permissive Security.

The security effects of Permissive Security are determined largely by changes made to SIP and other controls. Although signatures are still validated throughout the chain of boot stages, ‘global’ signatures are trusted for iBoot and beyond, as are boot objects signed locally by the Secure Enclave. At its most extensive, this allows the use of a fully untrusted kernel, such as a debug or custom version. The penalty is that some decryption keys are no longer available, and those restrict features available in macOS, such as Apple Pay, which is normally disabled.

Reversing Permissive Security requires fully enabling SIP using csrutil, undoing any other relevant security settings, then using Startup Security Utility to set a higher level of security. In some cases, that may entail installing a fresh macOS with its SSV. Apple also notes that, on Apple silicon Macs, SIP settings aren’t stored in NVRAM but in the LocalPolicy.

External Boot Volumes

With the notable exception of Big Sur, boot security settings are saved into the LocalPolicy for the boot volume group containing that paired Recovery system, although all LocalPolicy settings are saved to the internal SSD, never to an external disk. This relies on the concept of ownership, as explained here. This can bring its own problems, as explored here.

Summary

• Unless there’s a good reason, leave boot volume groups in Apple silicon Macs in Full Security.
• If your Mac needs to load a third-party kernel extension, run it in Reduced Security with those kernel extensions enabled.
• Partially or completely disabling SIP requires Permissive Security, which brings significant penalties, and may require more extensive work to undo.
• Use Startup Security Utility rather than bputil.

Reference

Apple’s Platform Security Guide

If you’ve become blasé with the tail end of the summer’s sport, Olympics and Paralympics, events next week should make compulsive viewing. Apple starts with its regular September launch of iPhones, and a day later we’ll be enthralled by the first TV debate between the two main contenders in the US presidential election. My money is on the iPhone 16 to win.

With those new iPhones comes the next major version of iOS, and hot on its heels macOS Sequoia 15.0. Without its AI features, that might seem the least exciting announcement of the week, but it prepares the ground for the next batch of Macs to be announced most probably in October, for shipping the following month. All commentators seem agreed that they will come not with M3 chips, but will be the first Macs to use the M4 family.

By now, different M-series chips are becoming blurry, so I’ll try to draw distinctions between them, and suggest why Apple has rushed through the M3 as if it might have been better-named the M2.5.

M1, November 2020

Skipping silently over Apple’s Developer Transition Kit from the summer of 2020, Apple silicon Macs started at a leisurely pace, as the four members of the M1 family rolled out over nearly 18 months. Their CPU cores ranged from the base version with 4 P and 4 E cores, 4P+4E in short, up to the impressive Ultra at 16P+4E. There was little separation, though, between the Pro and Max versions, which both came with 8P+2E, and only really differed in their GPUs. Thus, in the M1 there only two fundamentally different CPU core configurations, 4P+4E and 8P+2E, each with up to four cores in a cluster. Both core types used Arm’s instruction set architecture (ISA) from 2018, designated ARMv8.5-A.

M2, July 2022

Some of us assumed that first cycle would prove the model for its successors, but we were wrong and getting wronger as time progresses. After a break of just four months, Apple leaped into the M2 cycle, which it shortened to just a year from the 4P+4E M2 base version in July 2022. This cycle Apple bumped the number of E cores in the higher versions, taking the Ultra to 16P+8E, but still leaving little distance between the Pro and Max versions, both with 8P+4E, and two fundamental core configurations and clusters of four.

What might have appeared at the time to be small change, an increment in the ISA to ARMv8.6-A from 2019, brought enhancements in matrix maths, support for bfloat16 numbers to help with AI, and additional virtualisation capability. Although the M2 series appeared evolutionary in performance, it has also proved more capable.

M3, November 2023

Introduction of the M3 came again after a brief break of around four months, in November 2023. This time there was no phased release, gradually building up through Pro and Max to Ultra. The lesser three all came together, and put more distance between Pro and Max versions. The base M3 stuck with the proven combination of 4P+4E, the Pro scaled up to 6P+6E, then the Max nearly doubled that at 12P+4E, making three fundamental core configurations. That was over nine months ago, and there’s still no sign of any doubled-up Ultra version. To match the M3 Pro and Max core counts, they now form clusters of up to six cores, a significant advance on the two previous families.

While the M3 kept to Arm’s ARMv8.6-A ISA, Apple redesigned the GPU to support Dynamic Caching, Mesh Shading, and hardware-accelerated ray tracing. There’s one oddity, though: as this is the same ISA as the M2, with its enhanced support for virtualisation, Apple has stated that nested virtualisation coming in Sequoia requires not an M2 chip, but the M3, with its identical ISA. I have yet to see an explanation for that requirement.

M4, May 2024

In the absence of any M3 Ultra, Apple caught us off-guard when in May of this year (only six months after the M3) it launched new iPad Pros with what we must assume is the base M4 version of 4P+6E, and the next Arm ISA of ARMv9.2-A from 2020. That enhances vector and matrix maths, and brings support for 1 GHz timers, enabling nanosecond time resolution. In addition to the GPU features added in the M3, those in the M4 now also have hardware accelerated AV1 decoding.

There have, of course, been many other changes between M1 and M4, including higher operating frequencies for CPU cores, growth in the capability of the neural engine (ANE), and better support for external displays in the base version.

M1 to M4

Assuming that we’re soon to be treated to a range of Macs running members of the M4 family, the pace of change is accelerating. Landmarks along the route so far include:

• Increased E cores and ARMv8.6-A ISA in the M2.
• Three core configurations, clusters of six cores, and extended GPU hardware support in the M3.
• Increased E cores, ARMv9.2-A ISA and extra GPU hardware support in the M4.

For those who have whetted their appetite for Apple silicon with an M1 or M2, the leap up to M4 should prove exhilarating. Bring on the M4 Mac Studio, please, no matter who ends up as President.

Postscript and non-apologia

A few have commented to me, either below or by email, that they find this article somehow “offensive” for its references to the US Presidential Election, specifically for “belittling” it. If you have reached the end of this article and feel that to be true, then once you have finished reading this postscript, please go back and read its first paragraph again, slowly and without imagining words or meanings that simply aren’t there.

The introductory paragraph is what is known in American (but not, yet, British) English as a lede, and introduction. It establishes that there are two important events taking place early this coming week: Apple’s Event, which is the link to the main body of the article, and the televised debate between “the two main contenders in the US presidential election”. I hope we all agree that those are both important events.

I deliberately refer to the latter as enthralling, a word whose implications appear not be understood by many. A thrall is literally a slave, someone in bondage, and the word has ambiguous connotations of both being fascinating and attention-holding (its more common usage today), and enslaving mentally or morally. I simply cannot think of a more appropriate word to describe that hugely important debate, and cannot understand how anyone could construe that as in any way belittling.

The sentence at the end of that lede, “my money is on the iPhone 16 to win” is a reference to the unpredictability of elections (don’t forget that we in the UK had our own General Election just two months ago), and for those who have deeper insight into events a reference to gambling. As any American knows, betting in the US on the outcome of the Presidential Election is illegal, although betting on events such as the date of the next general election, or its outcome, remains perfectly legal in the UK. However, there were several scandals in the UK concerning people close to the former Prime Minister who placed successful bets on that date, and the hidden reference here is to those scandalous events still under investigation.

The final para in the article then refers back to the lede, a common technique when rounding off articles. In no way does it dismiss the importance of the election, but is an expressed wish that whatever disaster might or might not take place, there are many of us looking forward to Apple’s future M4 Macs, in my case specifically a new Mac Studio M4. Yes, it is a little light-hearted, after all this article is more of an editorial, as I’m sure you’re aware.

If you still find this offensive, then I’m sorry, but you really do need to read what is written, and not what you wish to imagine it’s saying.

The most difficult question when setting up a backup scheme is determining how much storage you need for all those backups. This article suggests how you can estimate how big that backup storage needs to be, assuming that you’re using incremental backup, like Time Machine, which keeps a sequence of older versions of each file in a series of multiple backups.

Basic formula

At its simplest, you need to estimate the size of the initial backup, and the average size of new backups each month for the period you intend using that storage. Then work out
initial backup size + (average monthly backups × number of months taking new backups)

Let’s say my Mac has a 1 TB internal SSD, with around 500 GB to be backed up, and each month 50 GB will be added to that. If I want to use that as my backup storage for 2 years, then it will need a capacity of
500 + (24 x 50) = 1700 GB
so a 2 TB drive should do fine for slightly longer.

In practice, Time Machine and other backup utilities are more frugal with the space they require, as they automatically ‘thin’ or remove some older backups. Time Machine’s policy is to keep:

• hourly backups for the previous 24 hours, in addition to hourly local snapshots on each volume being backed up,
• daily backups over the last month,
• weekly backups back to the start of that backup series.

Initial backup size

When backing up data-only volumes, like media libraries, almost everything on them is likely to be backed up initially. Significant exceptions include hidden folders containing Spotlight indexes and version databases; the former can be substantial, and can be measured by showing hidden files in the Finder, selecting the .Spotlight-V100 folder, and inspecting its size in the Get Info dialog. The latter can only be measured in Terminal, and can be safely ignored. Another hidden occupier of free space are snapshots, whose size can be estimated in Disk Utility.

Estimating backup size from a boot volume group, such as that containing your Home folder, is far harder. Time Machine and other backup utilities will only back up the Data volume in any case, and it usually holds many files and folders that aren’t backed up, in addition to its Spotlight indexes and version database. You may be able to gain an estimate from the Storage item in General settings, although that tends to lump a great deal into its System Data, some of which will be backed up, and some won’t.

If you use iCloud Drive much, particularly if you keep your Desktop and Documents folders in iCloud Drive and Optimise Mac Storage is enabled so that many files are evicted from local storage, you’ll need to consider how that might change if many of those items are downloaded, and can then be backed up. Another consideration is whether your backups will preserve sparse files at their reduced size, or expand them to full size. Again, that’s difficult to estimate, although Time Machine will normally retain their small size when backing them up to APFS.

Incremental backup rate

If you’re already backing up a volume, and it’s likely to see similar use in the future, use records of recent backups to estimate their daily or weekly total size. For Time Machine, you can do that using my free utility T2M2 (The Time Machine Mechanic). This provides:

• current free space in backup storage, which you can track over a week or so;
• actual free space and thinning size each time an old backup is thinned;
• total file size copied in each backup.

Save those records each day for a week, and you’ll get a very good idea as to how much additional space is required for the period you’re intending to keep those backups in that store.

Full backup storage

Another decision to make is what you’re going to do when that storage is full. If you’re using Time Machine, those backups are stored as snapshots, so at present can’t be copied across to another disk to retain in your archives. The only options are to reformat the volume for reuse, or to retain it as an archive. If you’re going to reuse that disk, consider whether it will still be large enough for use when it comes to the end of its backup series.

Summary

• Estimate initial backup size from the total used by all volumes to be backed up.
• Your boot volume group won’t require as much backup space as it uses, and Storage settings may help you guess how much to reduce that.
• Estimate the rate of growth using current backups, where available, from reports in T2M2.
• Decide how long you want to back up to that storage, thus how much your backups will grow over time.
• Then Total space required = initial backup size + (monthly increment × number of months in use).