What does Safe Mode do to an M1 Mac?

Apple gives precious little detail about what happens when you start your Mac up in safe mode. Here’s what is recorded in the Monterey User Guide:
“Safe mode may help you resolve or isolate problems that you’re having with your Mac.
When you start up in safe mode, your Mac prevents some software, such as startup items, from loading, and it performs a check of your startup disk. Your Mac may take longer to start up because of the check.”

This article explains what really does happen when you start an M1 Mac, specifically an M1 Pro running macOS 12.1, in safe mode. M1 Macs can’t be started up in safe mode using a key combination as Intel models are: the Mac first has to be started in Recovery mode by holding the Power button during startup. From there, select the startup disk, hold the Shift key, and the button which appears below that disk will change to offer it as the safe mode boot disk.

Does safe mode run fsck?

In macOS Mojave, starting up in safe mode caused a full check of mounted volumes using fsck, which checks all snapshots too, so could result in extremely long startup times. Apple stopped doing that in Catalina, and hasn’t reinstated it in Monterey either. There’s no evidence in the Unified log that any volumes are checked using fsck, and the fsck_apfs log only reports the same quick checks being made as in a regular startup.

Apple’s current Help information is thus at best misleading. If you want your volumes checked properly using fsck, you’ll have to start up in Recovery mode and use Disk Utility, or fsck_apfs in Terminal.

Does safe mode block some kernel extensions?

The kernel extension manager kernelmanagerd behaves quite differently during safe boot. It doesn’t load any of the kernel extensions in the Auxiliary Kernel Collection (AKC), reporting:
kernelmanagerd safe boot: Not loading auxkc

It also manages some of the standard macOS kernel extensions differently, and some may not be loaded. Among those are the following, which aren’t loaded until after the user has logged in:
/System/Library/DriverExtensions/IOUserBluetoothSerialDriver.dext
/Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext
/System/Library/DriverExtensions/com.apple.DriverKit-AppleEthernetIXGBE.dext
/System/Library/DriverExtensions/com.apple.DriverKit-UVCUserService.dext

However, all those kernel extensions in the main Kernel Collection appear to be loaded normally.

Apple doesn’t explain this in the Help information.

Launch, Login and Startup Items

While standard system LaunchAgents and LaunchDaemons appear to be run as normal, third-party items seem to be blocked completely. This also applies to user StartupItems. For example, after user login, the following appears in the log:
loginwindow -[LoginItemsLauncher main] | enter, safeboot = 1
loginwindow -[LoginItemsLauncher main] | exiting

Other subsystems affected

Open Directory, as both root and user, reports that safe boot is enabled, and is likely to change its behaviour as a result. Endpoint security similarly detects safe boot mode, as does SecurityAgent:
FDE SecurityAgent loginsupport Autologin disabled by safe boot
FDE SecurityAgent loginsupport Unable to autologin EFI user "hoakley"

Which caches are flushed?

There are no log entries which report the flushing of caches such as font caches. Most visible caches, such as those used by Launch Services to list recent apps and documents, are completely unaffected by safe boot.

What happens when you restart?

The strangest behaviour of all isn’t in safe mode itself, but what happens when you next restart your Mac to return to normal user mode. For that restart, and that one alone, validation of the SSV appears to be skipped.

During startup in safe or normal mode, preparations for validation of the SSV are marked by a lengthy passage of entries in the Unified log, summarised succinctly in:
import_iboot_forwarded_roothash:2843: importing root hash (basesystem ? 0)...
AppleFileSystemDriver: publishing boot-uuid-media=disk3s1 (Macintosh HD)
Got boot device = IOService:/AppleARMPE/arm-io/AppleT600xIO/ans@8F400000/AppleASCWrapV4/iop-ans-nub/RTBuddyV2/RTBuddyService/AppleANS3NVMeController/NS_01@1/IOBlockStorageDriver/APPLE SSD AP2048R Media/IOGUIDPartitionScheme/Container@2/AppleAPFSContainerScheme/AppleAPFSMedia/AppleAPFSContainer/Macintosh HD@1
BSD root: disk3s1
apfs_vfsop_mount:2188: disk3s1 Rooting from snapshot with xid 183952.
apfs_log_mount_unmount:1828: disk3s1 mounting volume Macintosh HD, requested by: kernel_task (pid 0); parent: kernel_task (pid 0)
handle_snapshot_mount:885: disk3s1 mounting snapshot w/snap_xid 183952 and sblock oid 0x23263e
is_root_hash_authentication_required_osx:369: disk3s1 Release kext with internal build: 0, ARV disabled: 0, booting xid: 0
is_root_hash_authentication_required:478: disk3s1 root volume, root hash authentication is required
authenticate_root_hash:546: disk3s1 successfully validated on-disk root hash

When a Mac is rebooting in normal mode after it has been in safe mode, many of those entries are absent from the log, which skips through to the requirement for root hash authentication:
import_iboot_forwarded_roothash:2843: importing root hash (basesystem ? 0)...
AppleFileSystemDriver: publishing boot-uuid-media=disk3s1 (Macintosh HD)
BSD root: disk3s1
is_root_hash_authentication_required_osx:369: disk3s1 Release kext with internal build: 0, ARV disabled: 0, booting xid: 0
is_root_hash_authentication_required:478: disk3s1 root volume, root hash authentication is required

However, on this occasion successful authentication isn’t recorded in the log, implying that requirement is never satisfied. I’ve been unable to duplicate that following a normal reboot, or a cold boot. That suggests that, when restarting from safe to normal mode, the full boot process isn’t performed. Whether that’s intended, or a bug, isn’t apparent.

Summary

Safe mode on an M1 Mac running Monterey 12.1 performs the following:

  • it blocks the loading of all third-party kernel extensions, and loads some system kernel extensions late;
  • it blocks third-party LaunchAgents, LaunchDaemons and StartupItems;
  • it may alter the behaviour of Open Directory, Endpoint Security and some autologins;
  • it might cause some caches to be flushed, but those remain unidentified;
  • the next reboot skips validation of the SSV.

It doesn’t perform any additional disk or volume checks, which ensures that safe boot takes the same time as a normal boot. If you want to check disks or volumes, that will have to be performed in Recovery mode instead.