There are so many controls in macOS that sometimes you can’t see the wood for the trees. This can leave uncertainty over essentials, such as whether your Apple silicon Mac really is properly secure, or maybe there’s something sinister going on with it? This is a question I’m asked not infrequently, usually when someone has been spreading disinformation or FUD (fear, uncertainty, doubt). So how can you check that your Mac is properly locked down and boots securely?

Quick checks

There are two quick checks that cover the essentials. First, open System Information and select the Controller section in Hardware.

This provides a brief summary of your Mac’s boot security, which should read as shown above. If you still need to use a kernel extension or similar, your Mac might show Reduced Security with Allow All Kernel Extensions enabled, but you should do everything you can to avoid that.

Secure Boot is controlled using Startup Security Utility in Recovery mode, and if you care to start up in that mode, you can confirm or correct its settings there.

Back in normal user mode, open Privacy & Security settings and ensure you have FileVault enabled there.

SilentKnight also checks that XProtect/Gatekeeper checks are enabled, and that security data are up to date, giving you complete confidence.

Details

Although those should be sufficient for most, some want to go further and verify that their Mac’s boot process and security systems are also working correctly. To do that, shut your Mac down, wait ten seconds or so, and start up normally with the startup chime sounding at a known time. Enter your password, wait a few seconds for the Finder to get set up and running, and open LogUI. Set its time to that of the startup chime, and get the first 10 seconds or 10,000 log entries. You may need to adjust the seconds to capture the full boot sequence. When you have, look through the log and identify the following waypoints.

In each of these log entries, I have emboldened a word or two that you can copy from here and paste into LogUI’s Search box, then press Return. That will display the log entry, and sometimes others you might find relevant. Times are given here in seconds, with the startup chime occurring at about 37 seconds. Version numbers shown are those for macOS 15.6.

The start of boot is recorded as
37.562774 === system boot: [UUID]
and a little while after that, the kernel declares its version details
42.759300 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
for macOS 15.6.

Further down you’ll come across more information about key security components, including the Trusted Execution Monitor
43.060422 [Log]: Code Signing Monitor Image4 Module Version 7.0.0: Fri Jul 11 16:51:29 PDT 2025; root:AppleImage4_txm-320.100.22~1090
43.060447 [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.37

Then the iBoot firmware version
43.061758 iBoot version: iBoot-11881.140.96
43.061760 iBoot Stage 2 version: iBoot-11881.140.96

CoreCrypto support is vital, and another Image4 extension
43.137635 FIPSPOST_KEXT [133796636] fipspost_post:154: [FIPSPOST][Module-ID] Apple corecrypto Module v18.3 [Apple silicon, Kernel, Software, SL1]
43.242334 Darwin Image4 Extension Version 7.0.0: Mon Jul 14 11:23:46 PDT 2025; root:AppleImage4-320.100.22~2585/AppleImage4/RELEASE_ARM64E

You should see entries reporting the loading of security policy components
43.242343 Security policy loaded: AppleImage4 hooks (AppleImage4)
43.242961 Security policy loaded: Apple Mobile File Integrity (AMFI)
43.243092 Security policy loaded: Seatbelt sandbox policy (Sandbox)

The Secure Enclave Processor or SEP is another key component that has to be started up
43.264594 "AppleSEPKeyStore":326:0: starting (BUILT: Jul 14 2025 23:34:10) ("normal" variant 🌽 , 1827.120.2)
43.264639 "AppleSEPKeyStore":471:0: _sep_enabled = 1

Apple System Policy should follow a bit later
43.760156 Security policy loaded: Apple System Policy (ASP)
43.760188 AppleSystemPolicy has been successfully started

The root of the file system is then identified in two entries whose origins go right back to the start of Mac OS X
43.940643 BSD root: disk3s1
43.940644 , major 1, minor 13

And APFS mounts the root file system, using the SSV snapshot
43.941048 apfs_vfsop_mountroot:2984: apfs: mountroot called!
44.034685 apfs_vfsop_mount:2763: disk3s1 Rooting from snapshot with xid 1724240.

One of the most important entries comes shortly after that, where successful validation of the SSV’s root hash is reported
44.038830 authenticate_root_hash:642: disk3s1 successfully validated on-disk root hash

It’s now time to start user space processes, and for that launchd must be loaded so it can launch everything else
44.103761 load_init_program: attempting to load /sbin/launchd

How Secure Boot works

Apple silicon Macs have a small ROM to support DFU mode in case a full Restore is required, and to check and load the first stage of the ‘firmware’, the Low-Level Bootloader or LLB. Only if that matches its signature will the ROM firmware hand over to it and proceed with the boot process. The LLB in turn performs the same checks on the second stage ‘firmware’, iBoot proper. That goes on to check the kernel, before loading that and handing over for kernel boot to take over.

iBoot ‘firmware’ doesn’t write anything in the log, but once the kernel takes over its log entries provide a detailed account of its progress. The great majority of its log entries are unintelligible to anyone outside Apple, but the waypoints I have given above identify some of the most important steps it takes. When it’s ready, the kernel validates the root hash for the SSV snapshot, as noted above, enabling the boot process to proceed to load and run other parts of macOS. The remaining hash checking of the SSV, to confirm that it’s exactly as Apple intends, proceeds in a ‘lazy’ fashion, as access is needed to its contents.

This chain of validation before loading the next stage ensures that nothing in the boot process can be tampered with or changed, and the boot is secure throughout. Apple provides further details in its Platform Security Guide.

If RunningBoard’s copious log entries record the life cycle of apps, can we use them to our advantage? To test this out, I’ve analysed a section of log using waypoints and information provided in RunningBoard’s entries.

Waypoints, or landmarks if you prefer, are essential for navigating the log. In an ideal world we would always know when any significant event occurred, timed to the millisecond. In practice we may only be able to estimate to the nearest few seconds or minutes. Without some means of discovering exactly when to obtain log extracts, you can waste many hours trying to pin down when something happened, and in many cases will be forced to abandon the hunt.

Methods

My aim was to separate RunningBoard log entries into those handling its assertions, which should represent life-cycle events, and job descriptions giving details of apps launched. To try this yourself, open LogUI and set the Start date and time to the start of the period of interest. Set the Period to at least 100 seconds, and Max entries to 2,000 or more. Then set the Predicate popup menu to read subsystem, and type in com.apple.runningboard so that LogUI only gets entries from that subsystem. Click on the Get Log tool in the toolbar, and check you get at least 1,000 entries.

Click on the Save JSON tool to save the whole of this excerpt. To view all the RunningBoard assertions acquired over that excerpt, type acquiring assertion in the search box at the top right, and press Enter.

The window name then changes to append the text from the search box.

To save this limited selection of entries, first click on the Reduce tool to discard all the others, then click on the Save JSON tool again and save the entries using a different filename. Repeat that using each of three search terms:

• acquiring assertion to see RunningBoard’s outline of life cycle events,
• constructed job to see job descriptions for newly launched apps,
• extension overlay to see similar information for appexes and similar extensions.

In my case, I analysed a period of 4 minutes of user activity on a Mac mini M4 Pro running macOS 15.6, during which there were 6,580 RunningBoard entries, suggesting that the whole log would have had well over 50,000 entries in that time, far too many to attempt any more detailed analysis. My search terms found 305 assertions acquired, 3 job descriptions constructed, and 20 extension overlays submitted.

Job descriptions

The three captured represented the three apps I had launched over those four minutes, Cormorant, DelightEd and Consolation 3. Each of them has a platform ID of 1, as notarized macOS apps. I also noticed that one was run in app translocation, although this was long after its first run. Recent versions of macOS, Sequoia in particular, appear prone to this, when an app that should have cleared quarantine gets stuck in perpetual app translocation.

Extension overlays

While I had expected to find those three app launches, I didn’t expect to see any appexes being run over this period. Those encountered consisted of three widgets, none of which had ever been opened, and five QuickLook thumbnail extensions. Most of these were run multiple times, with ScappleThumbnail appearing on six occasions. All were platform 1, except for the widgets, all three of which are bundled in macOS, for the FindMy widget and NewsToday2. They were platform 6, and subject to RunningBoard’s resource controls.

RunningBoard’s log entries here give potentially valuable insights that might otherwise be missed.

Assertions

It’s straightforward to construct a narrative of the key events that took place over that period of 4 minutes using a selection of assertions acquired. Rather than reproduce the whole of each of those waypoints, here they are laid out in more readable form.

11:40:50.424950 Acquiring assertion targeting app application.co.eclecticlight.Cormorant.10809046.10809052(501)
description "LS launch co.eclecticlight.Cormorant" ID:424-620-716
target: application.co.eclecticlight.Cormorant.10809046.10809052(501)
attributes: domain:"com.apple.launchservicesd" name:"LaunchRoleUserInteractive" sourceEnvironment:"(null)"

This marks the start of the launch process for Cormorant, handled in the normal way through LaunchServices and RunningBoard.

11:41:18.304367 Acquiring assertion targeting app application.co.eclecticlight.DelightEd.10206240.10206246(501)
description "LS launch co.eclecticlight.DelightEd" ID:424-620-756
target: application.co.eclecticlight.DelightEd.10206240.10206246(501)
attributes: domain:"com.apple.launchservicesd" name:"LaunchRoleUserInteractive" sourceEnvironment:"(null)"

This is the same for DelightEd.

11:41:20.050166 Acquiring assertion targeting [xpcservice com.apple.appkit.xpc.openAndSavePanelService([app application.co.eclecticlight.DelightEd.10206240.10206246(501) :1553])(501) 1576:1576]
description "viewBridge:1576" ID:424-391-769
target: 1576
attributes: domain:"com.apple.launchservicesd" name:"RoleViewBridge" sourceEnvironment:"(null)"

DelightEd is here being used to open a document using the openAndSavePanelService, a separate process.

11:41:44.171636 Acquiring assertion targeting app application.co.eclecticlight.Consolation3.430650.430692(501)
description "LS launch co.eclecticlight.Consolation3" ID:424-620-788
target: application.co.eclecticlight.Consolation3.430650.430692(501)
attributes: domain:"com.apple.launchservicesd" name:"LaunchRoleUserInteractive" sourceEnvironment:"(null)"

This is the launch of Consolation 3, a user error on this occasion!

Two long runs of assertions were discovered, both involving syncing the address book for Contacts.

11:41:57.462118 Acquiring assertion targeting [osservice com.apple.AddressBook.SourceSync(501):1610]
description "App is holding power assertion" ID:424-362-811
target: 1610
attributes: domain:"com.apple.appnap" name:"PowerAssertion" sourceEnvironment:"(null)", RBSAcquisitionCompletionAttribute policy:AfterApplication

The first of these was to sync the Address Book with its source in iCloud, and lasted 12.181 seconds.

11:42:11.840349 Acquiring assertion targeting [osservice com.apple.AddressBook.abd(501):1625]
description "Contacts shared filesystem lock" ID:424-1625-857
target: 1625
attributes: domain:"com.apple.common" name:"FinishTaskUninterruptable" sourceEnvironment:"(null)", RBSAcquisitionCompletionAttribute policy:AfterApplication

Shortly after that completed, synced data was updated by a service abd (Address Book Daemon?) that I had been unaware of. This only lasted 2.238 seconds.

RunningBoard’s assertions seldom appear for single-shot shell commands, and most commonly handle executable bundles rather than bare Mach-O binaries. They also don’t appear to provide clear information recording when apps are quit normally.

Conclusions

• RunningBoard entries can readily provide accurate waypoints for many events in the log.
• Establishing waypoints on the strength of RunningBoard log entries is straightforward in LogUI.
• Job descriptions are readily found, and provide useful information on apps launched.
• Extension overlays provide details of appexes that might otherwise be overlooked.
• Acquisition of assertions identify various events in the app life cycle.
• Once RunningBoard entries have provided precise times of events, attention can be focussed on obtaining more detail using short log extracts.

One thing we humans are good at is searching. It’s a task we engage in from a few moments after birth until the time we slip away in death, we search everything around us. Locating and identifying that bird of prey wheeling high, finding the house keys, and that book we mislaid some time last week, meeting the perfect partner, discovering the right job, choosing the best education, looking through a Where’s Wally? or Where’s Waldo? book, and so on. Searching has transformed some into explorers like Christopher Columbus, and was the purpose of the chivalric quest. It’s what researchers in every field do, and thanks to Douglas Adams can be answered by the number 42.

Last week my searching took two new turns.

Spotlight

The first was more of a meta-search, in trying to discover more about the internals of Spotlight. Following the example of Maynard Handley, who has used them so successfully in understanding how M-series CPUs work, I looked through patents that have been awarded to Apple for the work of its search engineers. Yesterday’s slightly fuller history of Spotlight search is one result, and there are more to come in the future as I digest those patents concerned with performing search.

There’s a tinge of irony here, as many of my searches have been conducted using Google Patents, alongside Google Scholar one of the remaining search engines that doesn’t yet use AI and attempt to provide its own answers.

Logs

The other marks a new phase in my quest to get more information from the Unified log. Looking back to my first comment here, I realise how wildly over-optimistic I was when I wrote that it “should make my life a lot easier”, and that “a new version of Console will provide improved features to help us wade through logs.” Nine years later, I look wistfully at what remains of Console and realise how wrong I was on both counts.

When RunningBoard arrived in macOS Catalina, I soon noticed how “its log entries are profuse, detailed, and largely uncensored for privacy.” Since then it has proved garrulous to the point where its apparently ceaseless log chatter is a distraction, and can overwhelm attempts to read other log entries. I suspect it has contributed significantly to those advanced Mac users who now refuse to even try to make sense of the log.

One answer might be to tweak log preferences to shut out this noise, but given the purpose of RunningBoard in monitoring the life cycle of apps, why not try to use the information it provides? To do that, it’s first necessary to understand RunningBoard’s idiosyncratic language of assertions, and its protocols under which they’re acquired. The only way to do that without documentation is by observation: catalogue over 30 of those assertions for an interesting example like Apple’s Developer app, and see what they reveal.

By far the most informative entries from RunningBoard are those announcing that it’s acquiring an assertion, such as
Acquiring assertion targeting [app<application.developer.apple.wwdc-Release.9312198.9312203(501)>:2946] from originator [osservice<com.apple.uikitsystemapp(501)>:748] with description <RBSAssertionDescriptor| "com.apple.frontboard.after-life.subordinate" ID:424-748-2228 target:2946 attributes:[
<RBSDomainAttribute| domain:"com.apple.frontboard" name:"AfterLife-Subordinate" sourceEnvironment:"(null)">
]>

In a log often censored to the point of being unintelligible, this contains frank and explicit detail. The app is identified clearly, with the user ID of 501 and process ID of 2946. The originator is similarly identified as com.apple.uikitsystemapp with its PID of 748, which is confirmed in the middle digits in the Assertion ID. This is explicitly related to FrontBoard and an attribute named AfterLife-Subordinate. There’s not a single <private> to blight this entry, although further knowledge is needed to decode it fully.

Normally to get such information from a running process would require its source code to be instrumented with calls to write log entries, many of which would be lost to <private>, yet RunningBoard seems happy, for the moment, to provide that information freely. You can see what I mean by applying the predicate
subsystem == "com.apple.runningboard" AND message CONTAINS "Acquiring assertion t"
in LogUI, to obtain a running commentary on active apps and processes. Once you’ve identified a relevant assertion, you can focus attention on other log entries immediately prior to that. I will be following this up in the coming week, with fuller instructions and some demonstrations.

Although neither patents nor assertions have the significance of the number 42, in their own ways they show how the art and science of search aren’t dead yet, nor have they succumbed to AI.

This is the last batch of ‘simple’ updates to my free apps to bring them up to the expectations of macOS 26 Tahoe. With them comes a minor update to my log browser LogUI, which is recommended for all using Tahoe, as it fixes an annoying if fundamentally cosmetic bug.

Preparing these updates for release was a little troublesome, as I attempted this using developer beta 3 of Tahoe and Xcode 26 beta 3. Little did I realise when I got all four rebuilt, tested and notarized, that this combination had stripped their shiny new Tahoe-compliant app icons. That made these new versions unusable in Sequoia and earlier, as they each displayed there with the generic app icon, despite working fine in Tahoe.

Eventually I discovered that I could build fully functional versions using Xcode 26 beta 2 in Sequoia 15.5, so that’s how they have been produced.

File integrity

Five years ago I build a suite of two apps and a command tool to enable checking the integrity of file data wherever it might be stored. This uses SHA256 hashes stored with each checked file as an extended attribute. At that time, the only alternative saved hashes to a file in the enclosing folder, which I considered to be suboptimal, as it required additional maintenance whenever files were moved or copied to another location. It made more sense to ensure that the hash travels with the file whose data integrity it verifies.

The three are Fintch, intended for use with single files and small collections, Dintch, for larger directories or whole volumes, and cintch, a command tool ideal for calling from your own scripts. As the latter has no interface beyond its options, it continues to work fine in macOS 26.

Since then other products have recognised the benefits of saving hashes as extended attributes, although some may now use SHA512 rather than SHA256 hashes. What may not be apparent is the disadvantage of that choice.

Checking the integrity of thousands of files and hundreds of GB of data is computationally intensive and takes a lot of time, even on fast M4 chips. It’s therefore essential to make that as efficient as possible. Although checksums would be much quicker than SHA256 hashes, they aren’t reliable enough to detect some changes in data. SHA algorithms have the valuable property of amplifying even small differences in data: changing a single bit in a 10 GB file results in a huge change in its SHA256 hash.

At the same time, the chances of ‘collisions’, in which two different files share the same hash, are extremely low. For SHA256, the probability that two arbitrary byte sequences share the same hash is one in 2^256, roughly one in 1.2 x 10^77. Using SHA512 changes that to one in 2^512, which is even more remote.

However, there ain’t no such thing as a free lunch, as going from SHA256 to SHA512 brings a substantial increase in the computational burden. When run on a Mac mini M4 Pro, using its internal SSD, SHA256 hashes are computed from files on disk at a speed of around 3 GB/s, but that falls to 1.8 GB/s when using SHA512 hashes instead.

Dintch provides two controls to optimise its performance: you can tune the size of its buffer to cope best with the combination of CPU and storage, and you can set it to run at one of three different QoS values. At its highest QoS, it will run preferentially on Apple silicon P cores for a best speed of 3 GB/s, while run at its lowest QoS it will be confined to the E cores for best energy economy, and a speed of around 0.6 GB/s for running long jobs unobtrusively in the background.

The two apps and cintch are mutually compatible, and with their earlier versions going back to macOS El Capitan. In more recent versions of macOS they use Apple’s CryptoKit for optimum performance.

Dintch version 1.8 is now available from here: dintch18
Fintch version 1.4 is now available from here: fintch14
and from their Product Page, from where you can also download cintch. Although they do use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with earlier versions.

Compression/decompression

Although I recommend Keka as a general compression and decompression utility, I also have a simple little app that I use with folders and files I transfer using FileVault. This only uses AppleArchive LZFSE, and strips any quarantine extended attributes when decompressing. It’s one of my testbeds for examining core allocation in Apple silicon Macs, so has extensive controls over QoS and performance, and offers manual settings as well as three presets.

Cormorant version 1.6 is now available from here: cormorant16
and from its Product Page. Although it does use the auto-update mechanism, I fear that changes in WordPress locations may not allow this to work with version 1.5 and earlier.

LogUI

Those using this new lightweight log browser in Tahoe will have discovered that, despite SwiftUI automatically laying out its controls, their changed sizes in Tahoe makes a mess of the seconds setting for times. This new version corrects that, and should be easier to use.

LogUI version 1 build 70 is now available from here: logui170

There will now be a pause in updates for macOS Tahoe until Apple has restored backward compatibility of app icons, hopefully in the next beta-releases.

Starting up a Mac, iPad or iPhone begins a series of processes progressing from their small boot ROMs to user login, starting up the services required for the operating system and booting the array of hardware in the chip. Early phases, before the kernel is booted, leave little in the way of records, just a few ‘breadcrumbs’ in NVRAM, but the kernel and processes it starts write a great many entries in the log. This article describes a few of those, concentrating on macOS 15.5, with additional information on iPadOS and iOS 18.5.

Logs

These were obtained from logarchives made soon after normal startup on:

• Mac mini M4 Pro, booting macOS 15.5 in Full Security mode from the internal SSD;
• iPad Pro 11-inch (4th generation)(Wi-Fi), with an M2 booting iPadOS 18.5 normally;
• iPhone 15 Pro, booting iOS 18.5 normally.

Logarchives were opened in LogUI and all log entries (excluding Signposts) were extracted for the first 5 seconds following the start of kernel boot and saved to a LogUI JSON file. Following correction for time adjustments (see below), those contained:

• for macOS, 20,000 entries in a total of 5.7 seconds;
• for iPadOS, 10,000 entries in a total of 5.7 seconds;
• for iOS, 10,000 entries in a total of 5.6 seconds.

Each set of entries opens with an entry recording the first moment of the boot process, for example
08:23:33.343017 === system boot: CCB8E0AC-5B94-4789-B951-BF0B893FF45F
following which there is a gap of over 5 seconds during which preboot is completed. The next entry then records the start of kernel boot, for example in macOS with
08:23:38.536777 kprintf initialized

Periods between those two entries were 5.2 seconds for macOS, 5.3 seconds for iPadOS, and 5.1 seconds for iOS.

Times and their correction

One potential source of major error in using log entries during startup results from clock time corrections. When started up, Macs and Apple’s devices appear invariably to have clock times about 6 seconds in advance of UTC. This is corrected about 4 seconds into kernel boot, and marked in two log entries such as
00.827884 === system wallclock time adjusted
00.860742 === system wallclock time adjusted
The first adjustment normally sets the clock back slightly more than necessary, but the second corrects that more accurately.

Effects on timestamps in log entries can appear confusing, as entries prior to time adjustment are given later timestamps than entries written after the adjustments have been made. This may give the impression that the order of log entries is incorrect, and any time calculations that depend on times recorded before and after adjustment require compensation by the two adjustments made. All times given below are taken from records made before system wallclock time adjustment, thus don’t require correction.

Time adjustments may need to be taken into consideration when accessing Endpoint Security events, as some may be written before adjustments are made, so might appear to be out of kilter with later events. This could apply to boot events for the launchd Subsystem, for example.

Log entries

Shortly after the start of kernel log entries with the initialisation of kprintf, the kernel banner is written, but only in macOS
Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041

Virtual memory, logging and other fundamental features are then prepared, and in macOS (not iPadOS or iOS) TXM, the Trusted Execution Monitor, is started
TXM [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.3
followed by the announcement of two stages of preboot, at 0.11 seconds after the start of kernel boot:
iBoot version: iBoot-11881.121.1
iBoot Stage 2 version: iBoot-11881.121.1

It’s notable that macOS gave an iBoot version of 11881.121.1, but iPadOS and iOS gave a slightly later version of 11881.122.1.

According to Apple, TXM (together with SPTM) is active on all three platforms, although it only appears to be well-reported in macOS. Apple explains: “Secure Page Table Monitor (SPTM) and Trusted Execution Monitor (TXM) on iOS, iPadOS, macOS and visionOS are designed to work together to help protect page tables for both user and kernel processes against modification, even when attackers have kernel write capabilities and can bypass control flow protections.” TXM then enforces the policies that govern code execution.

The kernel then turns its attention to loading Core Crypto support, reported in detail in all three platforms, and support for Image4 files, used extensively during and after boot:
0.295967 Darwin Image4 Extension Version 7.0.0: Tue Apr 22 19:44:19 PDT 2025; root:AppleImage4-320.100.22~1926/AppleImage4/RELEASE_ARM64E
and security policy is loaded (reported in macOS only).

AMFI and credential management

All three platforms then report loading of Apple Mobile File Integrity (AMFI), which obtains the model designator from the device tree:
AMFI: queried model name from device tree: Mac16,11
AMFI: queried model name from device tree: iPad14,3
AMFI: queried model name from device tree: iPhone16,1
which is probably the simplest way to confirm the model identifier from the log at this stage. On iOS only, AMFI next reports disabling Swift Playgrounds JIT:
AMFI: disabling Swift Playgrounds JIT services on iPhone devices

The kernel then turns to management of credentials with Credential Manager, which works with secrets managed by the Secure Enclave Processor (SEP) (all platforms). One key log entry to look for is the report of SEP Key Store startup,
"AppleSEPKeyStore":326:0: starting (BUILT: Apr 22 2025 19:45:09) ("normal" variant 🌽 , 1827.120.2)

Startup of hardware systems continues, with Bluetooth reported early, followed by IOThunderboltFamily, and the Apple Neural Engine ANE. In macOS only, the remains of an old copyright notice will then appear:
Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved.
iPadOS and iOS report Backlight startup in
AppleARMBacklight::start: Using new Backlight Architecture 1

CPU cores

After those, in macOS only, the log records registration of CPU cores and their clusters, then starts each in turn. Prior to this, all code has been run on a single core, but once the others have been started, multiple cores are available. The exact log entries recording this may vary between different M families, but typically run as follows:

• ml_processor_register>pset_find(cluster_id=0) returned pset -1
• ml_processor_register>pset_create(cluster_id=0) returned pset 0
• ml_processor_register>cpu_id 0x0 cluster_id 0 cpu_number 0 is type 1
• repeated to create each cluster and allocate CPUs to them, then
• cpu_start() cpu: 0
• arm_cpu_init(): cpu 0 online
• for each CPU in turn.

Although the iPad tested has an M2 chip, no such sequence was reported for its CPU cores in the log.

Security policy

macOS reports Gatekeeper status and the start of AppleSystemPolicy:
AppleSystemPolicy GK status: enabled
AppleSystemPolicy Per file changetime scans: enabled
Security policy loaded: Apple System Policy (ASP)
AppleSystemPolicy has been successfully started

APFS

APFS follows, with differences between log entries according to platform. Initial loading is announced in each, giving the version number
apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.120.31, apfs-2332.120.31.0.2, 2025/04/22
In macOS only, NFS is announced shortly afterwards
com_apple_filesystems_nfs: successfully loaded NFS module
and handling individual file system devices follows.

Boot devices are recorded in full:
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16GFamilyIO/ans@9600000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP2048Z Media/IOGUIDPartitionScheme/Container@2/AppleAPFSContainerScheme/AppleAPFSMedia
/AppleAPFSContainer/Macintosh HD@1 (macOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleT811xIO/ans@77400000/AppleASCWrapV4
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0512Z Media/IOGUIDPartitionScheme/Container@1 (iPadOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16IO/ans@F9400000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0128Z Media/IOGUIDPartitionScheme/Container@1 (iOS)

Each platform states the BSD root in a paired entry:
BSD root: disk3s1
, major 1, minor 15
By that time, the boot process is well underway and log entries are being made every few microseconds.

Key points

• Log entry times need to be corrected when they straddle clock adjustments marked by === system wallclock time adjusted
• === system boot: marks the start of preboot, following which there are no log entries for over 5 seconds before kernel boot starts.
• Start of Trusted Execution Monitor (TXM) is only logged in macOS, although it’s also active in iPadOS and iOS.
• iBoot versions may differ between macOS, and iPadOS/iOS.
• An early log entry from AMFI reports the model designator.
• AMFI reports disabling Swift Playgrounds JIT services on iPhones.
• In macOS only, CPU clusters and cores are registered, and started up individually.
• macOS then reports Gatekeeper (GK) status and the start of AppleSystemPolicy.
• The boot device is reported in full.
• Throughout these, many other services and hardware features are started up.
• During early kernel boot, macOS writes 20,000 log entries in about 5.7 seconds, iPadOS and iOS 10,000.

Volume structure of internal startup disks has grown increasingly complex during the transition from Intel to Apple silicon Macs. There also seems to be little information on iOS and iPadOS to compare against. This article briefly reviews structures of macOS 15 Sequoia on Apple silicon, iOS 18 and iPadOS 18.

Information for macOS is derived from the diskutil command tool, and from APFS entries in the log when booting a Mac mini M4 Pro in macOS 15.5. That for iOS is drawn from APFS entries in the log when booting an iPhone 15 Pro in iOS 18.5. That for iPadOS is drawn from APFS entries in the log when booting an iPad Pro 11-inch (4th generation)(Wi-Fi) in iPadOS 18.5. All three had Apple Intelligence enabled prior to booting. iOS and iPadOS logs were obtained from sysdiagnoses, and all logs were read using LogUI.

macOS 15 (Apple silicon)

The boot volume group consists of six volumes in a single container (partition). Two other containers are normally hidden from the user:

• the first container of around 524 MB is reserved for preboot and secure boot support.
• another container of about 5.4 GB is used for fallback recovery frOS, and in Big Sur was the primary recovery system, until the introduction of paired recovery volumes in macOS 12 Monterey.

The boot volume group contains:

• System, left unmounted after booting from its Signed System Volume (SSV) snapshot;
• Data, the only encrypted volume in the group, with numerous cryptexes grafted into it, and firmlinked to the SSV at multiple points;
• paired, primary Recovery, containing a disk image of the Recovery system;
• VM, the backing store for virtual memory;
• Preboot, for early stages in the secure boot process, with cryptexes grafted into it;
• Update, used as a working volume for macOS updates.

There are two groups of cryptexes grafted onto those volumes:

• system cryptexes, including the large SystemCryptex or os.dmg of about 4.3 GB mainly containing dyld caches, and the smaller AppCryptex or app.dmg containing Safari and supporting components;
• PFK volumes containing support components for Apple Intelligence features. These are numerous, and some are listed in the Appendix at the end.

If you’re wondering what a PFK volume might be, so am I. But this is what Google’s AI had to say: “Mac PFK” likely refers to a combination of MAC knives and Practical Fishkeeping (PFK) magazine. MAC knives are known for their high-quality, sharp blades and are popular among chefs and home cooks. Practical Fishkeeping is a magazine focused on fishkeeping, covering various aspects of the hobby.

These are summarised, without the help of Practical Fishkeeping, in this diagram.

iPadOS 18

In contrast to macOS since Big Sur, iPadOS and iOS only appear to have two containers (partitions) on their internal storage. The first is presumed to be similar in purpose to that in macOS, in supporting preboot and secure boot, although there is a xART volume in the boot volume group. In iPadOS, this container is smaller, at around 367 MB.

The boot volume group contains a slightly different range of volumes:

• there is no Recovery volume;
• there is no VM volume, as iPadOS doesn’t ordinarily support swapping/paging, although M-series models can in certain circumstances;
• User, a second encrypted volume, appears unique to iPadOS;
• xART and Hardware volumes are additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

iOS 18

This is similar to iPadOS, with a first container/partition of around 351 MB, and the following differences in the boot volume group:

• there is no User volume, and no Update volume;
• Baseband Data is additional.

Cryptexes appear similar, with both system cryptexes and PFK volumes.

These are summarised below.

Conclusions

• Volume structure of internal startup disks differs considerably between macOS, iPadOS and iOS.
• As would be expected, iPadOS and iOS are most similar, but even they have substantial differences.
• They each run their systems from a Signed System Volume firmlinked to an encrypted Data volume.
• They each graft on two sets of cryptexes, one supplementing the system with dyld caches and Safari, the other providing components for AI.
• There are now at least 24 cryptexes used to support AI.

I welcome corrections and explanations, please.

Appendix: Some PFK volumes from cryptexes

• UC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_300M_BAUC_FM_LANGUAGE_INSTRUCT_300M_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_DRAFTS_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_CONCISE_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAIL_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_BASE_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROFESSIONAL_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_SUMMARIZATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_PROOFREADING_REVIEW_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_EVENT_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MESSAGES_REPLY_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_AUTONAMING_MESSAGES_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_URGENCY_CLASSIFICATION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_FRIENDLY_TONE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_HANDWRITING_SYNTHESIS_MULTILINGUAL_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_VISUAL_IMAGE_DIFFUSION_V1_BASE_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_MULTILINGUAL_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_TEXT_PERSON_EXTRACTION_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_FM_LANGUAGE_INSTRUCT_3B_MAGIC_REWRITE_DRAFT_GENERIC_GENERIC_H14G_Cryptex.dmg
• UC_IF_PLANNER_NLROUTER_BASE_EN_GENERIC_H14G_Cryptex.dmg

Source: iPadOS 18.5, configured with AI enabled for British English.

SilentKnight’s history goes back to an unfortunate error in late 2016 when Apple shipped a batch of brand new MacBook Pros with SIP inadvertently disabled. At that time the only way to tell that was in Terminal, so I set about creating an app to make it easier to check. That became the first release of LockRattler in December 2016.

Demand for this grew steadily, as did LockRattler, and within a year it was checking additional security data in macOS.

At the same time it became clear from several reports that some Macs had EFI firmware that was woefully out of date. Some models were particularly prone to this, but at the time there were no lists of up-to-date firmware versions, and no local means to check them. In the summer of 2019, I started development on what was to become SilentKnight, originally named EFIcienC. This relied on a database that I built from looking inside macOS updaters to discover the latest firmware versions that should have been installed, but sometimes weren’t.

That soon took the familiar look of SilentKnight.

Three years later, there wasn’t much that SilentKnight didn’t check for.

Since the first version of SilentKnight, Apple has steadily been putting its house in order, and Macs have undergone great change. Next year’s major version of macOS 27 will no longer support Intel Macs, and that questions whether there’s a role for SilentKnight in the future.

Much of what SilentKnight does today is rapidly becoming redundant:

• T2 and Apple silicon firmware updates are now reliable and tied to macOS versions, so no longer need to be checked separately.
• In Apple silicon Macs, disabling SIP requires reducing boot security, so doesn’t need to be checked separately.
• XProtect updates are now delivered via iCloud and are more reliable, and not amenable to forced update.
• XProtect Remediator updates have become infrequent, every month or so.
• XProtect Remediator scans require separate, more detailed checks to interpret them properly.
• The TCC database has changed and is no longer updated as it used to be.
• Few security data updates are now delivered by softwareupdate.

Although SilentKnight has been a comfort over the last six years, its value is declining rapidly, and I don’t intend supporting it for macOS 27. It will though continue to support Macs running Tahoe and earlier, including all Intel models. Instead, I’d much prefer to develop Skint as a lightweight replacement for Apple silicon Macs in the future. Please provide me with your thoughts in comments here.

For those still using LockRattler, that hasn’t been updated for Sonoma or later, and the command tool companion to SilentKnight, silnite, doesn’t support Sequoia or later. They have both given good service over the years, but Macs and macOS have moved on.

XProCheck 1.7

If you use SilentKnight, you’ll be aware that XProtect Remediator scans have changed over the last year or so. Prior to that, the only time that scans by its plugins were cancelled was after an update. Now they’re run against a timer, and if they overstay their time limit, that plugin scan is cancelled. When this first started to occur, it wasn’t clear whether this was going to be a lasting behaviour, but it’s now well-established and common if not universal.

This new version of XProCheck now reports cancelled scans separately, using a emoji rather than a warning. I have also optimised its main view to look better when running in macOS 26 Tahoe, and made its app icon compatible with Tahoe’s requirements.

XProCheck 1.7 for macOS Big Sur and later is now available from here: xprocheck17
from its Product Page, and via its auto-update mechanism.

LogUI 1.0 build 68

Although this new build of my log browser LogUI is primarily to improve compatibility with macOS 26 Tahoe, including a new conformant app icon, this may bring a pleasant surprise for those who want to browse huge log extracts. According to a presentation at this year’s WWDC, “on macOS, lists of over 100,000 items now load six times faster.”

LogUI 1.0 build 68 for macOS Sonoma and later is now available from here: logui168
and from its Product Page.

App icons

Even if you didn’t watch any of the presentations at WWDC this year, you should by now have noticed that app icons are changing for Tahoe. Please bear with me as I progressively bring mine into conformance. I will explain more, with illustrations, in my Sunday morning article here.

Just before the start of WWDC, I released an update to my log browser LogUI adding support for accessing logarchives. I promised that there was more support for logarchives on its way. LogUI 1.0 build 65 dedicates a whole window to them, in its Logarchive Tool.

There are many situations where you can’t access the active log, and you can’t create a logarchive using the log command tool or a sysdiagnose. These include:

• When you only have access to the contents of the Mac or device’s storage, particularly in forensics, or following hardware failure.
• When you want access to the logs in a backup. Time Machine backups normally include full log files, for example.
• When you don’t have ssh or similar access to a remote Mac.
• When the log records may be incomplete or damaged.

Provided that you can copy two folders from the hidden /var/db folder on that Mac or device, LogUI can turn those into a browsable logarchive.

Create a logarchive from folders

On your Mac, create a folder somewhere convenient such as ~/Documents. As this method doesn’t use the log command, this can be on an external disk if you wish.

From the source Data volume copy the folders at /var/db/diagnostics and /var/db/uuidtext to your folder, so it looks like this.

Open LogUI, and from its Window menu open its Logarchive Tool. This offers you four tools and two checkboxes. Click on the Create Logarchive tool and first select the folder you created, containing the log folders. Then give the new logarchive a suitable name and save it somewhere convenient.

LogUI should then inform you in its window that creation has completed. As this is performed using undocumented code for an undocumented format, it may not always work correctly. If there are any problems, repeat the same with the Debug checkbox ticked, and it will give you a detailed commentary of what it does, which should help you understand what went wrong.

Getting info about a logarchive

The trickiest part of accessing logarchives is knowing what they contain, more specifically the time periods for which they have log records. LogUI’s Logarchive window provides two aids to provide you with that information, in its Catalogue and Analyse tools.

Catalogue simply lists all the tracev3 files in the logarchive, giving the datestamps each was created and last modified, together with the period between those, and the file size.

Leave that open as you browse that logarchive, to guide your way through its entries.

Analyse goes further, in telling you about the entries in each of the persist tracev3 files in the logarchive. It tells you the most common processes that wrote the entries in each of those files, allowing you to hone in on which are of most interest. If you want to extract that information for analysis in a spreadsheet, tick the CSV checkbox and it will be shown ready to import into your favourite spreadsheet.

Finally, to save the contents of the current window as a text file, click on the Save Text tool at the right.

I have now checked LogUI’s compatibility with the first developer beta of Tahoe, and found and fixed one obscure bug in the Logarchive Tool before this new build. LogUI should now be fully compatible with macOS 14.6 and later, including Tahoe. It’s available now from here: logui165
and from its Product Page.

Enjoy!

Until now, LogUI has only been able to access the active log of your Mac, by reading it directly. There are occasions when you can’t do that, or want to preserve the log for future reference. You also can’t browse the log directly on any of Apple’s devices. In these cases, and others, the best solution is to make a logarchive, and browse that instead. I’m delighted to provide an update to LogUI that can browse logarchives, including those created in iOS, iPadOS, and on Apple’s other devices.

What is a logarchive?

A logarchive is an undocumented package containing copies of all the files from the active log at the moment the logarchive was created. They can be opened and browsed by Console, Consolation 3, Ulbow, the log command tool, and now by LogUI. Because they contain all the files that make up the log, they can be large, and typically range in size from about 300 MB to over 1 GB. All the files containing log entries are stored in their original binary tracev3 format, proprietary to Apple, and again undocumented, although that format has been reversed in the past.

Create a logarchive

The easiest way to create a logarchive is to run a sysdiagnose, and that’s the standard way for saving a logarchive on one of Apple’s devices. Methods vary by device, and include:

• On a Mac, use the System Diagnostics… option in Activity Monitor’s Action tool, or press the Shift, Command, Control, Option and . keys at the same time, or run sudo sysdiagnose -f ~/Documents to save it to your Documents folder.
• On an iPhone or iPad, press and hold both volume buttons and the side or top button at the same time, for about 2 seconds. This combination may trigger other features, though. The sysdiagnose file will be made available in Settings > Privacy & Security > Analytics & Improvements > Analytics Data, from where you can transfer it to your Mac.

Unpack the .tar.gz archive resulting from that, and you’ll find a system_logs.logarchive inside it.

On a Mac, you can instead use the log collect command to create a logarchive directly. For example,
log collect --output ~/Documents/my.logarchive --last 5m
collects the last 5 minutes of log in the specified logarchive package. macOS security will block you from trying to save that logarchive on an external volume, though.

My free log browser Ulbow uses another method for assembling logarchives, and the next build of LogUI will incorporate that and other tools for working with logarchives.

Browse a logarchive in LogUI

This new build of LogUI has a seventh tool, to Use Logarchive. Click on that and you’ll be prompted to select the logarchive to open and browse.

Because the dates and times used in the logarchive will be different from current clock time, the LogUI window displays red warning text just to the left of the Start time. Set the date and time to a period within the scope of that logarchive, and use the Get Log tool as normal.

The log excerpt shown in the screenshot above is taken from the kernel boot sequence of my iPhone 15 Pro, to demonstrate how this all works.

If you want to return that window to browsing the active log, click on the Use Logarchive tool again, but this time cancel the selection. Other windows will of course continue to browse the active log unless you set them to use a logarchive as well.

Coming soon

Although browsing saved log entries in a logarchive is exactly the same as those of the active log, dates and times can be a pain. If you want to check when log files in a logarchive were written, use the Finder’s contextual menu to show their contents, scroll to the foot of the folders inside, select the Persist folder and check the file creation dates there.

This is made even easier in the forthcoming new build of LogUI, which features a Logarchive Tool to help you navigate logarchives, and learn which date and time ranges are appropriate.

LogUI 1.0 build 60 is now available from here: logui160
and from its Product Page.

I’ll be along with a new build in a few days, once I have tested and documented its Logarchive Tool. In the meantime, I hope you’ll find LogUI useful for studying the first beta-releases of Apple’s new operating systems.

Until now, LogUI has largely been an interactive log browser, and only able to export log excerpts in Rich Text format. This new build adds three tools to greatly increase its usefulness, as it can now write log excerpts in JSON format, open saved files, and filter out unwanted log entries. To give a simple example, this screenshot shows a log extract that has been reduced to entries made only by LaunchServices, converted from JSON to CSV, and imported into Numbers.

There are three new tools in LogUI’s toolbar.

From the left:

• Get Log fetches and displays log entries specified by the current log settings, as before.
• Read JSON opens a dialog for you select a LogUI JSON file, and loads its log entries into the window, replacing its current contents.
• Gloss opens the Gloss window with message text from selected log entries, enabling you to use Writing Tools and other aids, as before.
• Reduce applies the current search to current log entries. This removes all entries that are excluded by that search, so reducing the number of log entries. If you want to keep a copy of the unreduced log, save it as a JSON file before reduction.
• Save JSON opens a dialog for you to save the current log records to a new LogUI JSON file. This has the type co.eclecticlight.loguilog, and the extension .logui, and can be used as a regular JSON export with other apps capable of importing JSON format.
• Save RTF saves the current log excerpt as a Rich Text Format file, using the same colour conventions, as before.

You can now filter log entries in several ways, one at a time or all together:

• You can apply a predicate to determine which log entries are fetched in the first place, perhaps limiting them to one or two subsystems.
• You can search for subsystems, sender or process names, or contents of messages in the search box.
• When you have filtered the displayed log entries to those that you want, you can reduce the excerpt to include just those, and save that excerpt.
• You can then open the saved, reduced excerpt and use further searches to navigate and analyse those entries.

As we’ve recently been discussing different types of Spotlight search, I should perhaps explain that LogUI’s search isn’t word-based, simply finds matching sequences of characters, and doesn’t support regex or wild card search. If you search for the characters arb, then it will find them in the words nearby and arbitrary, but not in arabesque.

There are two current limitations with these new JSON documents. If you double-click one, LogUI should launch automatically and will then open a new window, but won’t load that document into the window, as that part of its internal wiring isn’t yet complete. The same also happens if you try dropping a document onto the app. I did hope to have drag and drop working in this release, but the resulting code proved too complex for the Swift compiler in Xcode to negotiate, so that will also wait for a future build.

LogUI 1.0 build 58 is now available from here: logui158
and from its Product Page.

This is likely to be the last update for a couple of weeks, as I expect I’ll be immersed in WWDC and its fallout for much of the next fortnight. My outstanding tasks are:

• complete the predicate editor in Settings;
• add support for opening documents from the Finder;
• add drag and drop support.

I’m also thinking about additional search/filter support, and whether a more compact binary document format might be a worthwhile alternative for large log excerpts.

As ever, I value your comments and suggestions.