https://eclecticlight.co/2021/12/29/how-secure-boot-works-on-m1-series-macs/ Skip to content [eclecticlight] The Eclectic Light Company Macs, painting, and more Main navigation Menu * Downloads * M1 Macs * Mac Problems * Mac articles * Art * Macs * Painting hoakley December 29, 2021 Macs, Technology How Secure Boot works on M1 series Macs We've come to assume that what we see in the Unified Log tells us what macOS is doing, once the system has been loaded by firmware. While that's largely correct for Intel Macs running UEFI firmware, and what the T2 does is kept pretty secret, Macs with M1 series chips are quite different. Look in the log of your M1 and you can watch much of the Secure Boot process in glorious detail, as this article explains. In the New Year, Apple is expected to update its Platform Security Guide to reflect changes brought in its latest M1 Pro and Max models, and with Monterey. For the time being, I rely on the current account, as summarised in the following diagram. M1bootSecurity2 The steps here are run first by the Boot ROM, then LLB (the Low-Level Bootloader), followed by iBoot (Stage 2), which hands over to macOS itself. On an M1 Pro Mac which started to boot at around 00 to 01 seconds on the system clock, the first 7-8 seconds of that process is omitted from the log, and consists of the Boot ROM and LLB phases. The first log entries from the kernel are 08.289794 === system boot: [UUID] 13.742101 kprintf initialized with a further gap of more than 5 seconds between them, during which there's further unrecorded LLB activity. What's then announced is a combination of the macOS kernel, xnu and iBoot all together 13.742296 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000 13.818102 iBoot version: iBoot-7429.61.2 To be able to validate and access LocalPolicy, and determine the level of security required, the kernel needs to load its validation tool for Image4 files, which is does next 13.989331 Darwin Image4 Validator Version 4.2.0: Tue Nov 30 21:45:44 PST 2021; root:AppleImage4-157.60.2~361/AppleImage4/RELEASE_ARM64E After that, security policy is loaded: 13.989783 AppleMobileFileIntegrity AMFI: UDID enforcement enabled 13.989801 calling mpo_policy_init for AMFI 13.989810 Security policy loaded: Apple Mobile File Integrity (AMFI) 13.989817 calling mpo_policy_init for Sandbox 13.989905 Security policy loaded: Seatbelt sandbox policy (Sandbox) 13.989966 calling mpo_policy_init for Quarantine 13.989970 Security policy loaded: Quarantine policy (Quarantine) Next comes starting the Secure Enclave key store: 14.065805 AppleSEPKeyStore:319:0: starting (BUILT: Nov 30 2021 21:31:02) From this time onwards, other parts of the chip are starting up and initialising. There are often copious log entries from each as it does. So far, all this has been run on a single core. It's now time to start all the others, which is performed by a series of calls to cpu_start, beginning with the first E processor 14.568080 ml_processor_register>cpu_id 0x0 cluster_id 0 cpu_number 0 is type 1 14.568126 cpu_start() cpu: 0 That's repeated until all ten cores are up and running. On the M1 Pro /Max, these are listed in three clusters: * cluster 0 contains the two E cores, type 1, numbers 0 and 1; * cluster 1 contains the first four P cores, type 2, numbers 2-5; * cluster 2 contains the remaining four P cores, type 2, numbers 6-9. The original M1 chip has just two clusters: * cluster 0 contains the four E cores, type 1, numbers 0-3; * cluster 1 contains the four P cores, type 2, numbers 4-7. Gatekeeper is then enabled 14.644687 AppleSystemPolicy GK status: enabled 14.644688 AppleSystemPolicy Per file changetime scans: enabled iBoot is now ready to access disk storage, so loads the APFS file system 14.779543 apfs apfs_module_start:2568: load: com.apple.filesystems.apfs, v1933.61.1, apfs-1933.61.1, 2021/11/30 The next task is to locate the boot volume, ready to mount its snapshot 14.827815 AppleFileSystemDriver AppleFileSystemDriver: publishing boot-uuid-media=disk3s1 (Macintosh HD) 14.828281 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 followed by the longstanding announcement of the BSD root 14.828295 BSD root: disk3s1 14.828300 , major 1, minor 13 Only now, nearly 15 seconds after its start, does the Mac get to root from the boot snapshot 14.898802 apfs apfs_vfsop_mount:2118: disk3 Promoter has been locked 14.899252 apfs apfs_vfsop_mount:2188: disk3s1 Rooting from snapshot with xid 183952. 14.899261 apfs apfs_log_mount_unmount:1828: disk3s1 mounting volume Macintosh HD, requested by: kernel_task (pid 0); parent: kernel_task (pid 0) 14.899386 apfs handle_snapshot_mount:885: disk3s1 mounting snapshot w /snap_xid 183952 and sblock oid 0x23263e The first task with that snapshot is to validate its seal 14.901008 apfs is_root_hash_authentication_required_osx:369: disk3s1 Release kext with internal build: 0, ARV disabled: 0, booting xid: 0 14.901013 apfs is_root_hash_authentication_required:478: disk3s1 root volume, root hash authentication is required 14.901018 apfs authenticate_root_hash:546: disk3s1 successfully validated on-disk root hash Next comes the Recovery volume within that boot container 14.910181 trying to find and mount BaseSystem dmg as root volume 14.910188 attempting kernel mount for recovery volume... 14.915623 apfs er_state_obj_get_for_recovery:6381: disk3s3 No ER state object for volume Recovery - rolling is not happening, nothing to recover. 14.915679 apfs handle_mount:654: disk3s3 vol-uuid: 4CDE4B2A-F463-49AA-AC77-D4DD774F4832 block size: 4096 block count: 487113810 (unencrypted; flags: 0x1; features: 1.0.2) 14.916518 apfs handle_mount:667: disk3s3 setting dev block size to 4096 from 512 14.916525 apfs nx_volume_group_update:7709: disk3s3 Volume Recovery role 4 Not a System or data volume 14.916803 mounted recovery volume Other volumes mounted include VM, Preboot and Update 15.095112 apfs apfs_log_mount_unmount:1828: disk3s6 mounting volume VM, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) 15.097235 apfs apfs_log_mount_unmount:1828: disk3s2 mounting volume Preboot, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) 15.102171 apfs apfs_log_mount_unmount:1828: disk3s4 mounting volume Update, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) Additionally, volumes in the Apple_APFS_ISC container are mounted as required 15.122871 apfs apfs_log_mount_unmount:1828: disk1s2 mounting volume xART, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) 15.125391 apfs apfs_log_mount_unmount:1828: disk1s1 mounting volume iSCPreboot, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) 15.128037 apfs apfs_log_mount_unmount:1828: disk1s3 mounting volume Hardware, requested by: apfs_boot_util (pid 2); parent: launchd (pid 1) The end of the kernel-only phase, which is entirely iBoot, comes almost 20 seconds after the start. From then on, processes other than the kernel are running, and filling much of the log. The first of these loads the Wi-Fi firmware 19.928393 wifiFirmwareLoader wifiFirmwareLoader Sandboxing init issue, couldn't find profile in default paths, attempting default compiled profile Immediately after that, the system clock is adjusted, and there's a hiatus when that occurs, here setting the clock back by 3.3 seconds 13.614115 === system wallclock time adjusted All this is still within what Apple terms iBoot. Its next task is to validate the Boot Kernel Collection and any auxiliary collection, using kernelmanagerd 13.642280 kernelmanagerd Starting userland kernel management subsystem (KernelManagement_executables-262.60.4) 14.121399 kernelmanagerd Disabling kext auditing: We are on Apple Silicon 14.137320 kernelmanagerd Initializing with settings: 14.139417 kernelmanagerd finding bundles in repositories: /Library/Extensions /Library/Apple/System/Library/Extensions /AppleInternal/Library/Extensions /System/AppleInternal/Library/AuxiliaryExtensions /System/AppleInternal/Diagnostics/AuxiliaryExtensions /System/Library/AuxiliaryExtensions /System/Library/DriverExtensions /Library/DriverExtensions kernelmanagerd then validates each of the Boot Kernel Collection with a log entry such as 14.164688 kernelmanagerd validating extension at /System/Library/ DriverExtensions/com.apple.DriverKit-AppleUSBFTDI.dext and many more. Once that's ready to load as a collection, that's reported 14.207370 kernelmanagerd Preparing collection load into kernel Each is acknowledged as it is loaded 14.316533 kernelmanagerd Received kext load notification: com.apple.kpi.bsd and many more Once kernelmanagerd has finished, the kernel shuts it down, and no more kernel extensions can be loaded 29.313999 Kext loading now disabled. 29.314006 Kext unloading now disabled. 29.314009 Kext autounloading now disabled. 29.314011 Kernel requests now disabled. 29.314448 kernelmanagerd Kernel requested shutdown. Goodbye! macOS is now loaded and running at last, almost 30 seconds after the start. Postscript: Isn't this just xnu? That's what I'd always thought the logs recorded, and that appears true for Intel Macs. However, look at the tasks which are being undertaken by the kernel throughout this period, and look at those stated by Apple, in its Platform Security Guide, as being performed by what it terms "iBoot (Stage 2)". One very simple example is the validation of the Boot Kernel Collection, and any Auxiliary Kernel Collection. Then compare with the log entries by kernelmanagerd above, which record exactly those processes occurring more than 3 seconds after the announcement of the xnu version. Either Apple is confused and incorrect, or these log entries are being made during the iBoot stage. It's also worth noting that one of the most important tasks of iBoot is to verify the Seal on the snapshot which forms the boot system and SSV. The log entries above demonstrate that being performed at around 14.9 seconds, once APFS has been loaded, which is a prerequisite for that task. Apple states explicitly that's a task of iBoot. Share this: * Twitter * Facebook * Reddit * Pinterest * Email * Print * Like this: Like Loading... Related Posted in Macs, Technology and tagged firmware, iBoot, kernel, kernel extension, LLB, M1, M1 Max, M1 Pro, macOS 12, Monterey, startup. Bookmark the permalink. 5Comments Add yours 1. 1 [39170b8ad072] rogparish on December 29, 2021 at 3:33 pm Reply I wonder how long that boot process would take with a spinning disk? LikeLiked by 2 people + 2 [2af76302b284] Duncan on December 29, 2021 at 4:21 pm Reply I'll let you know when mine finishes. LikeLiked by 1 person o 3 [6986a746f627] hoakley on December 29, 2021 at 7:55 pm Reply Presumably by postcard? Actually, one of the great joys of the T2 and M1 are that they have stopped marketing from insisting on selling some unfortunate customers Macs with slow internal storage. Howard. LikeLike + 4 [8bd8b6fcb4d6] David C. on December 29, 2021 at 8:00 pm Reply I don't know about on an M1 Mac, but on my Intel Mac, booting Big Sur from a USB hard drive takes several minutes. And even after I'm logged in to a working desktop, the drive never seems to stop thrashing, so everything runs too slow for comfort. The conclusion is that HDDs are not in any way usable with modern versions of macOS. In an emergency, they can let you get access to some critical files, but you really won't want to be running your Mac like this for longer than the time necessary to install/replace an SSD, (re-)install macOS and restore your documents/apps from a backup. LikeLiked by 1 person o 5 [6986a746f627] hoakley on December 29, 2021 at 10:48 pm Reply The problem isn't macOS, it's APFS, and I and many others have been saying this since High Sierra. The clincher was Mike Bombich's careful measurements of fragmentation in the file system metadata. Please don't use APFS on hard disks unless (a) the data is going to remain essentially static, as in a disk used as an archive, or (b) it's a Time Machine backup store, which also remains relatively static in this respect, because of the structure of APFS backups. Using a hard disk as a boot disk is purgatory. Howard. LikeLike Leave a Reply Cancel reply Enter your comment here... [ ] Fill in your details below or click an icon to log in: * * * * Gravatar Email (required) (Address never made public) [ ] Name (required) [ ] Website [ ] WordPress.com Logo You are commenting using your WordPress.com account. ( Log Out / Change ) Google photo You are commenting using your Google account. ( Log Out / Change ) Twitter picture You are commenting using your Twitter account. ( Log Out / Change ) Facebook photo You are commenting using your Facebook account. ( Log Out / Change ) Cancel Connecting to %s [ ] Notify me of new comments via email. [ ] Notify me of new posts via email. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. Quick Links * Downloads * Mac Troubleshooting Summary * M1 Macs * Mac problem-solving * Painting topics * Painting * Long Reads Search Search for: [ ] [Search] Monthly archives * December 2021 (71) * November 2021 (72) * October 2021 (75) * September 2021 (76) * August 2021 (75) * July 2021 (75) * June 2021 (71) * May 2021 (80) * April 2021 (79) * March 2021 (77) * February 2021 (75) * January 2021 (75) * December 2020 (77) * November 2020 (84) * October 2020 (81) * September 2020 (79) * August 2020 (103) * July 2020 (81) * June 2020 (78) * May 2020 (78) * April 2020 (81) * March 2020 (86) * February 2020 (77) * January 2020 (86) * December 2019 (82) * November 2019 (74) * October 2019 (89) * September 2019 (80) * August 2019 (91) * July 2019 (95) * June 2019 (88) * May 2019 (91) * April 2019 (79) * March 2019 (78) * February 2019 (71) * January 2019 (69) * December 2018 (79) * November 2018 (71) * October 2018 (78) * September 2018 (76) * August 2018 (78) * July 2018 (76) * June 2018 (77) * May 2018 (71) * April 2018 (67) * March 2018 (73) * February 2018 (67) * January 2018 (83) * December 2017 (94) * November 2017 (73) * October 2017 (86) * September 2017 (92) * August 2017 (69) * July 2017 (81) * June 2017 (76) * May 2017 (90) * April 2017 (76) * March 2017 (79) * February 2017 (65) * January 2017 (76) * December 2016 (75) * November 2016 (68) * October 2016 (76) * September 2016 (78) * August 2016 (70) * July 2016 (74) * June 2016 (66) * May 2016 (71) * April 2016 (67) * March 2016 (71) * February 2016 (68) * January 2016 (90) * December 2015 (96) * November 2015 (103) * October 2015 (119) * September 2015 (115) * August 2015 (117) * July 2015 (117) * June 2015 (105) * May 2015 (111) * April 2015 (119) * March 2015 (69) * February 2015 (54) * January 2015 (39) Tags Adobe APFS Apple AppleScript Apple silicon App Store backup Big Sur Blake Bonnard bug bugs Catalina Consolation Console Corinth diagnosis Disk Utility Dore El Capitan extended attributes Finder firmware Gatekeeper Gerome HFS+ High Sierra history history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 malware Metamorphoses Mojave Monet Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism riddle Rubens Sargent scripting security Sierra Swift symbolism Time Machine Turner update upgrade xattr Xcode XProtect Statistics * 10,604,647 hits Blog at WordPress.com. Footer navigation * About & Contact * Macs * Painting * Language * Tech * Life * General * Downloads * Mac problem-solving * Extended attributes (xattrs) * Painting topics * Hieronymus Bosch * English language * LockRattler: 10.12 Sierra * LockRattler: 10.13 High Sierra * LockRattler: 10.11 El Capitan * Updates: El Capitan * Updates: Sierra, High Sierra, Mojave, Catalina, Big Sur * LockRattler: 10.14 Mojave * SilentKnight, silnite, LockRattler, SystHist & Scrub * DelightEd & Podofyllin * xattred, Metamer, Sandstrip & xattr tools * 32-bitCheck & ArchiChect * T2M2, Ulbow, Consolation and log utilities * Cirrus & Bailiff * Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma * Revisionist & DeepTools * Text Utilities: Nalaprop, Dystextia and others * PDF * Keychains & Permissions * LockRattler: 10.15 Catalina * Updates * Spundle, Cormorant, Stibium, Dintch, Fintch and cintch * Long Reads * LockRattler: 11.0 Big Sur * Mac Troubleshooting Summary * M1 Macs * Mints: a multifunction utility * LockRattler: 12.x Monterey Secondary navigation * Search Post navigation Don Quixote 38: The hunting party and the first trick Don Quixote 39: Sancho's letter Search for: [ ] [Search] Begin typing your search above and press return to search. Press Esc to cancel. * Follow Following + [wpcom-] The Eclectic Light Company Join 5,128 other followers [ ] Sign me up + Already have a WordPress.com account? Log in now. * + [wpcom-] The Eclectic Light Company + Customize + Follow Following + Sign up + Log in + Copy shortlink + Report this content + View post in Reader + Manage subscriptions + Collapse this bar Loading Comments... Write a Comment... [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. %d bloggers like this: [b]