Virtual Machines running macOS on Apple silicon Macs are more versatile than the host they run on. When you want to create a new VM, or modify an existing one, there are some powerful options available.
One of the most useful is to duplicate an existing VM: as APFS will do that using clone files, and the virtual disk in a VM is stored as a sparse file, that will use much less disk space than making a completely new VM. If you’re likely to need a supply of VMs running the same version of macOS, why not create a base VM using the IPSW for that version, duplicate it, then set up each clone as you require?
For even more flexibility, you can increase the size of the VM as I have already explained. The only remaining problem is how you can migrate the contents of one VM to another. Although my previous attempts to do this had been unsuccessful, Michael was kind enough to provide the solution, and this article explains how to use Migration Assistant in two VMs running concurrently to copy the contents of one VM to another, on the same host Mac. This should also enable you to migrate between a VM and a Mac.
To perform a successful migration, Migration Assistant needs to connect to a mounted Data volume on local storage, or over a network. It can’t use a VM shared folder on the host as the source (server). If your virtualiser supports root level access to USB storage, enabling it to mount an external disk in the VM, then you should be able to migrate from a Time Machine or other backup on that disk. Migration can be performed during initial setup and customisation of macOS, or by running Migration Assistant later. In this walkthrough, I’ll use the former.
You need
To do this, the virtualiser has two fundamental requirements:
it must be able to run two macOS VMs concurrently,
you must be able to assign them different MAC addresses.
Apple enforces a limit of two macOS VMs running concurrently on the same Mac, a rule written into the macOS license. Although that might seem stingy, macOS isn’t like Linux and you can’t run Tahoe on a single core with a mere 3-4 GB of memory. However, if you can spare at least 3 P cores and around 12 GB of memory for each, there should be ample to perform a migration. In practice, that means the host Mac should have a total of eight or more P cores, and at least 32 GB of memory.
MAC addresses are supposed to be unique. As the connection between these two VMs is over your local network, your DHCP server must allocate them two different IP addresses, or they won’t be able to migrate. The way to ensure that works is to assign each VM its own and different MAC address.
My own free Viable satisfies both requirements. Here I’ll use that to set up a new VM as the migration client, using an existing VM as the server. For the sake of simplicity, I’ll assume the MAC address of the server is the default, and won’t change that.
Procedure
This uses two macOS VMs running at the same time:
the destination for the migrated files is a new VM and is the migration client,
the source of those files is an existing VM and is the migration server.
Start by installing the IPSW to create your new VM. Rather than going straight on to its first run, at this stage open the server VM with the default MAC set, log into it, and locate Migration Assistant in /Applications/Utilities ready to run.
Now change the MAC address in Viable’s window to something different. I used d6:a7:58:8e:79:d4 instead of d6:a7:58:8e:78:d4. Then open the new VM, the migration client, and take it through its configuration, opting to migrate to it from another Mac.
When you reach the screen that sets that up, open Migration Assistant on the server VM, and set it to transfer data To another Mac. Then switch back to the client VM, and you should see that server offered as the source for your migration. Select it and perform the PIN authorisation so they can connect.
On the client, select the items you want to migrate to that VM, and proceed.
After a few minutes, the migration should complete, allowing the client to finish setting up with its new user account. You can then shut down the server and reset the MAC address and other settings in Viable.
Summary
Viable’s narrative documents the sequence:
Install the IPSW to create the new client VM.
Start up the server VM with 3 cores and 12 GB memory, and the default MAC of d6:a7:58:8e:78:d4.
Start up the client VM, with the same cores and memory, and a different MAC of d6:a7:58:8e:79:d4
When the new (client) VM reaches the Transfer information to this Mac window, open Migration Assistant on the server (old) VM and set it to transfer To another Mac.
Select the items to migrate on the new (client) Mac and proceed.
This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 26.0 Tahoe.
Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. Intel models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs just give an iBoot version.
Macs still running older versions of macOS are covered by information at:
The current EFI version is 2092.0.0.0.0 and iBridge is 23.16.10350.0.0,0.
Apple Studio Display
The current version remains 17.0 (build 21A329).
How to check your Mac’s firmware version
The simplest way is to run my free tool SilentKnight, available from its product page.
Alternatively, use the About This Mac command at the top of the Apple menu; hold the Option key and click on the System Information command. In the Hardware Overview listing, this is given as the Boot ROM Version or System Firmware Version.
What to do if your Mac’s firmware is different from that shown
If the version is higher than that given here, it indicates that Mac has installed a more recent version of macOS, which has installed a later version of the firmware. This is almost invariably the result of installing a beta-release of the next version of macOS. This occurs even when the newer macOS is installed to an external disk.
If the installed version of firmware has a version lower than that shown, you can try installing macOS again to see if that updates the firmware correctly. If it still fails to update, you should contact Apple Support.
Firmware updaters are now only distributed as part of macOS updates and upgrades: Apple doesn’t provide them separately.
All T2 and Apple silicon models automatically check the integrity of their firmware in the early part of the boot process anyway. If any errors are found then, the Mac should be put into DFU mode and firmware restored from the current IPSW image file. In Sonoma and later this can be performed in the Finder, and no longer requires Apple Configurator 2. Full instructions are provided in this article. If you don’t have a second Mac or don’t feel that you can perform this yourself, it should be easy to arrange with an Apple store or authorised service provider.
A couple of weeks ago I estimated how much power and energy were used when performing Visual Look Up (VLU) on an Apple silicon Mac, and was surprised to discover how little that was, concluding that “it’s not actually that demanding on the capability of the hardware”. This article returns to those measurements and looks in more detail at what the CPU cores and GPU were doing.
That previous article gives full details of what I did. In brief, this was performed on a Mac mini M4 Pro running macOS Sequoia 15.6.1, using an image of cattle in a field, opened in Preview. powermetrics collected samples in periods of 100 ms throughout, and a full log extract was obtained to relate time to logged events.
Power use by CPU cores, GPU and neural engine (ANE) are shown in this chart from that article. This tallies against log records for the main work in VLU being performed in samples 10-24, representing a time interval of approximately 1.0-2.4 seconds after the start. There were also briefer periods of activity around 3.2 seconds on the GPU, 4.2 seconds on the CPU, and 6.6-7.1 seconds on the CPU. The latter correlated with online access to Apple’s SMOOT service to populate and display the VLU window.
To gain further detail, powermetrics measurements of CPU core cluster frequencies, active residencies of each core, and GPU frequency and active residency, were analysed for the first 80 collection periods.
Frequency and active residency
Cluster frequencies in MHz are shown in the chart above for the one E and two P clusters, and the GPU. These show:
The E cores (black) ran at a baseline of 1200-1300 MHz for much of the time, reaching their maximum frequency of 2592 MHz during the main VLU period at 1.0-2.4 seconds.
The first P cluster (blue), P0, was active in short bursts over the first 1.5 seconds, and again between 6.3-7.0 seconds. For the remainder of the period the cluster was shut down.
The second P cluster (red), P1, was most active during the three periods of high power use, although it didn’t quite reach its maximum frequency of 4512 MHz. When there was little core activity, it was left to idle at 1260 MHz but wasn’t shut down.
The GPU (yellow) ran at 338 MHz or was shut down for almost all the time, with one brief peak at 927 MHz.
This chart shows the total active residencies for each of the three CPU clusters, obtained by adding their % measurements. Thus the maximum for the E cluster is 400%, and 500% for each of the two P clusters, and 1,400% in all. These are broadly equivalent to the CPU % shown in Activity Monitor, and take no account of frequency. These show:
The E cores (pale blue) had the highest active residency throughout, ranging from as little as 30% when almost idle around 5 seconds, to just over 300% during the main VLU phase at 1.4 seconds.
The first P cluster (purple) remained almost inactive throughout.
The second P cluster (red) was only active during the periods of highest work, particularly between 1.0-2.4 seconds and again at 6.4-7.1 seconds. For much of the rest of the test it had close to zero active residency.
Taken together, these show that a substantial proportion of the processing undertaken in VLU was performed by the E cores, with shorter peaks of activity in some of the cores in the second P cluster. For much of the time, though, all ten P cores were either idle or shut down.
Load
Combining frequency and active residency into a single value is difficult for the two types of CPU core. To provide a rough metric, I have calculated ‘cluster load’ as total cluster active residency x (cluster frequency / maximum core frequency)
where the maximum frequency of these E cores is taken as 2592 MHz, and the P cores as 4512 MHz. For example, in the sample period at 2.2 seconds, the P1 cluster frequency was 4449 MHz, and the total active residency for the five cores was 122%. Thus the P1 cluster load was 122 x (4449/4512) = 120.3%. Maximum load for that cluster would have been 500%.
The chart above shows load values for:
The E cluster (black) riseing to 150-260% during the peak of VLU activity, from a baseline of 20-30%.
The P0 cluster (blue) which never reached 10% after the initial sample at 0 seconds.
The P1 cluster (red) spiking at 90-150% during the three most active phases, otherwise remaining below 10%.
Caution is required when comparing E with P cores on this measurement, as not only is E core maximum frequency only 57% that of P cores, but it’s generally assumed that their maximum processing capacity is roughly half that of P cores. Even with that reservation, it’s clear that a substantial proportion of the processing performed in this VLU was on the E cores, with just one cluster of P cores active in short spikes.
Finally, it’s possible to examine the correlation between total P cluster load and total CPU power.
This chart shows calculated total P load and reported total CPU power use. The linear regression shown is CPU power = 4.1 + (42.2 x total load)
giving a power use of 4,200 mW for a load of 100%, equating to a single P core running at maximum frequency.
Conclusions
Cluster frequencies and active residencies measured in CPU cores followed the same phases as seen in CPU power, with most of the processing load of VLU in the the early stage, between 1.0-2.4 seconds, a shorter peak at 6.6-7.1 seconds correlating with online lookup, and a small peak at about 4.2 seconds.
A substantial proportion of the processing performed for VLU was run on E rather than P cores, with P cores only being used for brief periods.
Visual Look Up used remarkably little of the capability of an M4 Pro chip.
Apple has announced that macOS 26 Tahoe will be released on Monday 15 September, slightly earlier than had been speculated. Even if you’re not intending to upgrade to that, you might instead be looking at moving from Sonoma to Sequoia, or perhaps dragging your feet and considering Sonoma as it enters its final year of support. This article considers what you should do when preparing to upgrade macOS.
One of the surgeons I worked for in my first internship in hospital taught me an important lesson in life: when considering the outcome of anything that could go wrong, assume that it will go wrong, and prepare for that. When it actually works out better than you planned for, you can enjoy your success.
Emergencies
The worst case is that your Mac dies during the upgrade. Although that’s also the least likely, you need to think through your disaster plan. I ensure that all my most essential files and data are shared or copied up to iCloud so that I could get by for a day or three without that Mac. A recent full backup is also essential: if your Mac needs to go away to be resuscitated, one way or another that’s what you’ll be restoring from.
Upgrades do bring a tiny but significant risk of bricking your Mac in a way that only a full Restore will recover it. Although this can apply to Intel Macs with T2 chips if a T2 firmware update goes wrong, this is more the preserve of Apple silicon Macs. I’ve recently stepped through your options with full details here. Your first DFU Restore is daunting, but once you’ve done one, you’ll realise that they’re not that challenging if you have the right cable and DFU port. When you’ve restored firmware and macOS, you’ll then be restoring from that last backup, emphasising its importance.
In the days before the SSV, when there was only one boot volume and that could so readily be corrupted during upgrades, you also needed to have an emergency toolkit handy to repair an upgrade that went wrong. These days, the whole of the System in the SSV is either perfect, or macOS has to be reinstalled. Minor glitches are almost invariably corrected by restarting after the upgrade has completed, or starting up in Safe mode (remember on Apple silicon Macs that’s performed from Recovery).
Reverting macOS
The other possibility that you should plan for is beating a hasty retreat and reverting to an older version of macOS. Provided that you’re fully aware of the changes to the macOS interface brought in Tahoe, I think this is less likely for those upgrading from Sequoia, but if you’re skipping a version or two you could still find yourself unable to use a vital peripheral or one of your key apps, leaving you with reversion as your only option.
I’m sometimes asked by eternal optimists whether you can revert to your previous macOS simply by using its SSV snapshot. Sadly, snapshots are of no help: the only way back is to wipe and reinstall that macOS.
On Intel Macs, you’ll need to do this when booted from an external bootable installer, which doesn’t have to be on a USB ‘thumb’ drive, but does still require its own HFS+ volume to work. Apple explains this here, and Mr. Macintosh has links to all available installer apps.
Although you can do that with an Apple silicon Mac, if you have a second Mac and the right USB-C cable, it’s usually quicker and simpler to do this by restoring from the appropriate IPSW file in DFU mode, then restoring your files from your latest backup, as explained here. This is particularly valuable, as it also restores the original firmware, which may be the root of your problems. Unfortunately, that doesn’t seem possible with Intel Macs. Once their firmware has been upgraded, the user isn’t able to downgrade it.
Checklist
Check you’re prepared to use your disaster plan if needed.
Consider sharing and copying to iCloud to help you use another Mac or device temporarily.
Make a full backup immediately before starting the upgrade.
Restart, or start up in Safe mode, if the upgrade leaves your Mac with problems.
Reverting to an older macOS isn’t trivial, and will require you to restore from your backup.
Revert an Intel Mac using a bootable external installer.
Consider reverting an Apple silicon Mac by restoring it in DFU mode, using an older IPSW.
Whatever you choose to do, I wish you success, and hope that your preparations prove completely unnecessary.
Why is it that a fast Apple silicon Mac takes so long to tar and Gzip a large folder? Surely, with all those fast Performance cores, even GB should be compressed in the twinkling of an eye? Could it be that macOS is running the tar command on its Efficiency cores instead, eking out the power? This article explores and explains how macOS sets the priority for command tools and similar binaries.
Threads
There are two key factors at work here. The first is threading, division of the work done by a process into single flows of execution run on one CPU core at a time. Every process has its main thread, and many can also create additional threads that can be scheduled to run in parallel. While macOS can and often will move threads around its cores, a single-threaded process can only run on a single CPU core at a time.
QoS
macOS also allocates threads to cores. Although neither you nor the process control that absolutely, processes can influence it by setting a Quality of Service, QoS, for each of their threads. QoS is chosen from the standard list:
QoS 9 (binary 001001), named background and intended for threads performing maintenance, which don’t need to be run with any higher priority.
QoS 17 (binary 010001), utility, for tasks the user doesn’t track actively.
QoS 25 (binary 011001), userInitiated, for tasks that the user needs to complete to be able to use the app.
QoS 33 (binary 100001), userInteractive, for user-interactive tasks, such as handling events and the app’s interface.
There’s also a ‘default’ value between 17 and 25, an unspecified value, and you might come across others used by macOS.
If all your Mac’s CPU cores are free and idling, macOS will normally allocate threads with a QoS of 17 (utility) and higher to P cores, and those of 9 (background) and lower to E cores. That isn’t guaranteed, and there are circumstances when all threads are allocated to E cores alone, for example when a laptop’s battery is very low and it goes into energy-saving mode.
CPU History
It’s therefore tempting to assume that when a process runs very slowly, it’s being given a low QoS and is pottering along on the E cores. Although that might be correct, it’s a dangerous assumption to make. In this case, to investigate it further, I’ll take a different compressor that offers control over the QoS used for its working threads, such as my free Cormorant or the wonderful Keka.
When compressing an IPSW file of just over 18 GB, using Apple Archive’s LZFSE method in Cormorant takes 7.4 seconds at the maximum QoS of 33, but 114.7 seconds at the minimum QoS of 9. Performing exactly the same compression using aa from the command line takes about 9 seconds, so is clearly being run at high QoS. But using tar to create a tar.gzip takes forever, even longer than Cormorant running at minimum QoS.
Activity Monitor’s CPU History window is a quick and simple way to see what’s going on here, although you must be cautious when trying to interpret values such as CPU %., because those shown don’t take into account the frequency cores are run at.
This is Cormorant compressing at high QoS on all 10 of the P cores.
And this is the same compression performed at low QoS, so confined to the 4 E cores.
Compressing using aa in Terminal also makes full use of all the P cores available.
Running tar in Terminal does use the P cores, but runs in a single thread that’s shuffled between cores and takes more than 10 times as long as it would if it could be run in 10 threads.
Thus, the reason that tar is so slow isn’t because it’s given a low QoS and run on the E cores, but that it’s single-threaded (and not performant either). If you want better performance, look for a substitute that can make good use of multiple threads running in multiple P cores.
Exceptions
There are plenty of binaries that are run at low QoS, hence on the E cores, including most of those that are run in the background or scheduled using LaunchAgents and LaunchDaemons. Their property lists should specify a QoS name for their Priority key, which is often Background or Maintenance, for them to be run at a QoS of 9 or lower on the E cores alone.
There’s also the possibility that a command tool may run its own threads and assign a low QoS to them, although that should always be documented.
Summary
By default, command tools run in Terminal aren’t assigned low QoS and run on E cores.
Tools that run in single threads will invariably be slower than multi-threaded equivalents.
Use Activity Monitor’s CPU History window to see which core types threads are run on.
If you’ve read any of my articles here about the inner workings of CPU cores in Apple silicon chips, you’ll know I’m no stranger to using the command tool powermetrics to discover what they’re up to. Last week I attempted something more adventurous when trying to estimate how much power and energy are used in a single Visual Look Up (VLU).
My previous tests have been far simpler: start powermetrics collecting sample periods using Terminal, then run a set number of core-intensive threads in my app AsmAttic, knowing those would complete before that sampling stopped. Analysing dozens of sets of measurements of core active residency, frequency and power use is pedestrian, but there’s no doubt as to when the tests were running, nor which cores they were using.
VLU was more intricate, in that once powermetrics had started sampling, I had to double-click an image to open it in Preview, wait until its Info tool showed stars to indicate that stage was complete, open the Info window, spot the buttons that appeared on recognised objects, select one and click on it to open the Look Up window. All steps had to be completed within the 10 seconds of sampling collections, leaving me with the task of matching nearly 11,000 log entries for that interval against sampling periods in powermetrics' hundred samples.
The first problem is syncing time between the log, which gives each entry down to the microsecond, and the sampling periods. Although the latter are supposed to be 100 ms duration, in practice powermetrics is slightly slower, and most ranged between about 116 and 129 ms. As the start time of each period is only given to the nearest second, it’s impossible to know exactly when each sample was obtained.
Correlating log entries with events apparent in the time-course of power use is also tricky. Some are obvious, and the start of sampling was perhaps the easiest giveaway as powermetrics has to be run using sudo to obtain elevated privileges, which leaves unmistakeable evidence in the log. Clicks made on Preview’s tools are readily missed, though, even when you have a good estimate of the time they occurred.
Thus, the sequence of events is known with confidence, and it’s not hard to establish when VLU was occurring. As a result, estimating overall power and energy use for the whole VLU also has good confidence, although establishing finer detail is more challenging.
The final caution applies to all power measurements made using powermetrics, that those are approximate and uncalibrated. What may be reported as 40 mW could be more like 10 or 100 mW.
In the midst of this abundance of caution, one fact stands clear: VLU hardly stresses any part of an Apple silicon chip. Power used during the peak of CPU core, GPU and neural engine (ANE) activity was a small fraction of the values measured during my previous core-intensive testing. At no time did the ten P cores in my M4 Pro come close to the power used when running more than one thread of intensive floating-point arithmetic, and the GPU and ANE spent much of time twiddling their thumbs.
Yet when Apple released VLU in macOS Monterey, it hadn’t been expecting to be able to implement it at all in Intel chips because of its computational demand. What still looks like magic can now be accomplished with ease even in a base M1 model. And when we care to leave our Macs running, mediaanalysisd will plod steadily through recently saved images performing object recognition and classification to add them to Spotlight’s indexes, enabling us to search images by labels describing their contents. Further digging in Apple’s documentation reveals that VLU and indexing of discovered object types is currently limited by language to English, French, German, Italian, Spanish and Japanese.
Some time in the next week or three, when Apple releases macOS Tahoe, we’ll start seeing Apple silicon Macs stretch their wings with the first apps to use its Foundation Models. These are based on the same Large Language Models (LLMs) already used in Writing Tools, and run entirely on-device, unlike ChatGPT. This has unfortunately been eclipsed by Tahoe’s controversial redesign, but as more developers get to grips with these new AI capabilities, you should start to see increasingly novel features appearing.
What developers will do with them is currently less certain. These LLMs are capable of working with text including dialogue, thus are likely to appear early in games, and should provide specialist variants of more generic Writing Tools. They can also return numbers rather than text, and suggest and execute commands and actions that could be used in predictive automation. Unlike previous support for AI techniques such as neural networks, Foundation Models present a simple, high-level interface that can require just a few lines of code.
If you’ve got an Apple silicon Mac, there’s a lot of potential coming in Tahoe, once you’ve jiggled its settings to accommodate its new style.
Look in the log, and Visual Look Up (VLU) on an Apple silicon Mac apparently involves a great deal of work, in both CPU cores and the neural engine (ANE). This article reports a first attempt to estimate power and energy use for a single VLU on an image.
To estimate this, I measured CPU, GPU and ANE power in sampling periods of 100 ms using powermetrics, and correlated events seen there with those recorded in a log extract over the same period, obtained using LogUI. The test was performed on a Mac mini M4 Pro running macOS 15.6.1, using Preview to perform the VLU on a single image showing a small group of cattle in an upland field. Power measurements were collected from a moment immediately before opening the image, and ceased several seconds after VLU was complete.
When used like this, powermetrics imposes remarkably little overhead on the CPU cores, but its sampling periods are neither exact nor identical. This makes it difficult to correlate log entries and their precise timestamps with sampling periods. While powermetrics gives power use in mW, those measurements aren’t calibrated and making assumptions about their accuracy is hazardous. Nevertheless, they remain the best estimates available.
Log narrative
The first step in log analysis was to identify the starting time of powermetrics sampling periods. Although execution of that command left no trace in its entries, as it has to be run with elevated privileges using sudo, its approval was obvious in entries concluding 30.677182 com.apple.opendirectoryd ODRecordVerifyPassword completed
A subsequent entry at 30.688828 seconds was thus chosen as the start time for sampling periods, and all times given below as given in seconds after that time zero.
The following relevant events were identified in the log extract at elapsed times given in seconds:
1.4 ANE started and an ObjectDetectionModel run for 0.2 s
1.6 ANE activity and a NatureWorldModel run for 0.25 s
2.0 ANE activity for 0.15 s
2.4 ANE activity for 0.1 s
8.1 ANE activity and a UnifiedModel run for 0.01 s
8.1 PegasusKit queried Apple’s SMOOT service, the external connection used to populate the VLU window.
Thus, the ANE was run almost continuously from 1.4-2.2 seconds after the start of sampling, otherwise was used little over the total period of about 9 seconds. Over that period of activity, an initial model used to detect objects was succeeded by a later model to identify objects in a ‘nature world’.
Power and energy estimates
From the log record, it was deduced that the VLU was started in powermetrics sample 10 (1.0 seconds elapsed), and essentially complete by sample 75 (7.5 seconds elapsed), a period of approximately 6.5 seconds, following which power use was low until the end of the sampling periods. All subsequent calculations refer to that series of samples and period of time.
Sums, averages and maxima of power measurements for that period of 6.5 seconds are:
CPU 64,289 mW total, 989 mW average, 7,083 mW maximum (10 P cores)
total 68,991 mW total, 1,061 mW average, 7,083 mW maximum.
Thus for the whole VLU, 93% of power was used by the CPU, 4.6% by the GPU, and only 2.2% by the ANE.
For comparison, in the M4 Pro chip running maximal in-core loads, each P core can use 1.3 W running floating point code, and 3 W running NEON code. The chip’s 20-core GPU was previously measured as using a steady maximum power of 20 W, with peaks at 25 W.
As each power sample covers 0.1 seconds, energy used during each sampling period is power/0.1, thus the total energy used over the 6.5 second period of VLU is:
CPU 6.4 J
GPU 0.3 J
ANE 0.2 J
total 6.9 J.
Those are small compared to the test threads used previously, which cost 3-8 J for each P core used.
Power over time
Power used in each 100 ms sampling period varied considerably over the whole 10 seconds. The chart below shows total power for the CPU.
Highest power was recorded between samples 10-25, corresponding to 1.0-2.5 seconds elapsed since the start of measurements, and most events identified in the log. Later bursts of power use occurred at about 4.2 seconds, and between 6.6-7.1 seconds, which most probably corresponded to opening the info window and performing the selected look-up.
Almost all power use by the neural engine occurred between 1.5-2.1 seconds, correlating well with the period in which substantial models were being run.
Peak GPU power use occurred around 1.0-1.5 seconds when the image was first displayed, at 3.1-3.2 seconds, and between 6.5-7.4 seconds. It’s not known whether any of those were the result of image processing for VLU as GPU-related log entries are unusual.
Composite total power use demonstrates how small and infrequent ANE and GPU use was in comparison to that of the CPU.
Conclusions
Given the limitations of this single set of measurements, I suggest that, on Apple silicon Macs
power and energy cost of VLU is remarkably low;
the great majority of work done in VLU is performed in the CPU;
although use of the neural engine may result in substantial performance improvements, VLU doesn’t make heavy demands on the neural engine in terms of power or energy use;
VLU may appear impressive, but it’s not actually that demanding on the capability of the hardware.
Inside every Intel Mac with a T2 chip, and every Apple silicon Mac, is a secure enclave, originally referred to as its security enclave. The subject of a flurry of Apple’s patents from 2012 onwards, this was introduced in the A7 chip inside the iPhone 5s and iPad mini 3, 12 years ago in September 2013, where it brought biometric authentication in Touch ID.
iPhone 5s
Protecting the most important secrets in a computer is a great challenge. No matter how secure you try to make the main processor and memory, as they’re exposed to direct attack, isolation can only be relative and temporary. An alternative approach is to move the most secure data and its processing into a secure enclave and its processor, and that’s the architectural solution chosen by Apple in what it patented as a security enclave, filed in September 2012, a year before its release in the iPhone 5s. Engineers credited for that patent are Manu Gulati, Michael J Smith and Shu-Yi Yu.
Successive iPhone chips steadily improved their secure enclaves, and by the time the iPhone 7 was introduced in September 2016, with its A10 Fusion chip, its secure enclave was handling encryption and authentication but not replay prevention. It also had EEPROM secure storage, and an AES engine with DPA protection and lockable seed bits. When the first Intel Mac with a T1 chip was released a couple of months later, that was based not on the A10 but the S2 used in the Apple Watch Series 2. The T1 thus doesn’t really have a secure enclave as such, although it supports Touch ID.
An early and thorough account of these secure enclaves was presented by Tarjei Mandt, Mathew Soling and David Wang at Black Hat USA in 2016. This appears to be the only such account apart from the section in Apple’s Platform Security Guide, most recently updated in December 2024. Apple’s engineers continued to gain new patents, covering trust zone support (filed in 2012), key management (filed in 2014), and most relevant to Macs, Pierre Olivier Martel, Arthur Mesh and Wade Benson’s patent for multi-user storage volume encryption, filed in 2020.
T2 chip
The first Macs with a true secure enclave are those with a T2 chip, starting with the iMac Pro in December 2017. Those are based on the same A10 Fusion chip from the previous year, and were already lagging the iPhone 8 in this respect.
The T2 secure enclave is another co-processor system, run by a Secure Enclave Processor (SEP), a 32-bit ARM CPU running its own operating system, sepOS, based on a specialised L4 microkernel completely different from those used by Macs and Apple’s devices. It has its own secure storage (EEPROM), and a Public Key Accelerator for signing and encryption/decryption using RSA and ECC methods. Outside the enclave is a dedicated AES256 encryption/decryption engine built into the data transfer path between the internal SSD and main system memory.
M-series chips
The big leap forward for Macs was the release of the first models featuring M1 chips, which caught up with the features of late versions (after autumn 2020) of the A12 and A13, with Apple’s second generation Secure Storage Component.
Perhaps the most significant of its improvements are measures to prevent replay attacks. Those are best illustrated with FileVault. Let’s say that you didn’t enable FileVault at first, but left your Apple silicon Mac to handle the encryption of its internal Data volume without the added protection of your password. That would mean that its volume encryption key (VEK) was generated internally by the Secure Enclave, and stored there. If you then turned FileVault on, the VEK would be encrypted using your password and the hardware key. In the T2 chip, it might be possible to use the old VEK to decrypt the volume. In the secure enclave of an M-series chip, that type of replay attack is prevented by the revocation of all previous events and records.
Other improvements include the use of second generation secure storage incorporating counter lockboxes to enforce limits on the number of passcode attempts allowed, instead of an EEPROM, and a better Public Key Accelerator.
Currently, the secure enclave is known to protect the following:
encryption keys for Touch ID, FileVault, and the Data Protection (iCloud) keychain (but not file-based keychains);
that Mac’s Unique ID (UID) and Group ID (GID);
Touch ID control, and (on older devices not Macs) Face ID using a secure neural engine; in recent devices and M-series chips, that’s implemented as a secure mode in the main neural engine (ANE);
Apple Pay handling;
Activation Lock, through the Owner and User Identity Keys;
signing and verification of LocalPolicy for boot environments (Apple silicon).
Communication between the CPU and SEP is performed using a dedicated mailbox whose function is detailed in Apple’s patents. Further information is also provided in the Platform Security Guide.
FileVault encryption
It has been stated widely (even here) that the secure enclave in T2 and Apple silicon chips contains a hardware encryption/decryption unit and acts as the internal SSD’s storage controller. In fact, as shown in the original patent of Martel and others, and now in the Platform Security Guide, the AES engine responsible is located outside the secure enclave, together with the Flash controller, and has a secure link to the enclave.
During SEP boot, it generates an ephemeral key to wrap keys to be used by the AES engine for encryption and decryption. That key is sent from the secure enclave to the AES engine over the dedicated connection between them, then used to protect keys transferred from the enclave to the AES engine. That ensures an unprotected key is never exposed outside the enclave and AES engine.
The Apple silicon secure enclave is by no means unique. ARM TrustZone, other Trusted Execution Environments, and Trusted Platform Modules offer similar features and facilities. However, the secure enclave is unusual because it has been integrated into all Macs with T2 or Apple silicon chips, and all Apple’s recent devices, and can’t be disabled or bypassed.
References
Manu Gulati, Michael J Smith and Shu-Yi Yu, US Patent 8,832,465 B2, Security enclave processor for a system on a chip, filed 25 September 2012, granted 9 September 2014.
R Stephen Polzin, James B Keller, Gerard R Williams, US Patent 8,775,757 B2, Trust zone support in system on a chip having security enclave processor, filed 25 September 2012, granted 8 July 2014.
R Stephen Polzin, Fabrice L Gautier, Mitchell D Adler, Conrad Sauerwald and Michael LH Brouwer, US Patent 9,419,794 B2, Key management using security enclave processor, filed 23 September 2014, granted 16 August 2016.
Pierre Olivier Martel, Arthur Mesh and Wade Benson, US Patent 11,455,432 B1, Multi-user storage volume encryption via secure processor, filed 8 June 2020, granted 27 September 2022.
Tarjei Mandt, Mathew Soling and David Wang (2016), Demystifying the Secure Enclave Processor, Black Hat USA 16 (PDF)
Apple, Platform Security Guide
Wikipedia’s overview of Apple silicon chips.
With careful observation and a little knowledge of the startup sequence of an Apple silicon Mac, you can learn a lot about what can and can’t happen during that sequence. This article explains how, with examples from the log of a Mac mini M4 Pro.
In broad terms, startup of an Apple silicon Mac consists of the following sequence of events:
Boot ROM, which ends in DFU mode if there’s a problem, otherwise it hands on to
the Low-Level Bootloader (LLB) and iBoot (Stage 2), the firmware, that should end in validating and running
the kernel, which initially runs on a single CPU core before starting others up and launching launchd, and later
unlocking and accessing the Data volume, and progressing to
userspace.
The opening entry in the log is the boot announcement of === system boot:
followed by the boot UUID. There’s then a gap of 5 seconds or more before the next entry, which marks the start of kernel boot. Those seconds are the silent phase during which the LLB and iBoot are doing their thing. They don’t write to the Unified log, but leave fragments of cryptic information known as breadcrumbs, which you can’t make use of. The kernel then writes its usual welcome of kprintf initialized
and the following four seconds or so are filled by log entries from the kernel.
Wallclock adjustment
During this phase, the system clock is synchronised, and wallclock time adjusted, usually twice in rapid succession. This is obvious by step changes in timestamp, usually putting the clock back by several seconds in the first sync, then putting it forward slightly in the second. These play havoc with the timestamps, as you can have two or even more instances of the same time being recorded in the log. Beware of the entries === system wallclock time adjusted
Early during the kernel phase, it starts up all the other CPU cores in the chip, and records that in the log. Entries become progressively more varied after launchd is loaded, and this first userspace boot (without Data volume access).
Data volume unlock
With FileVault enabled, by this stage macOS still doesn’t have access to the Data volume. That means all the code run so far, and almost all the data, are immutable, locked in the firmware or the Signed System Volume (SSV). The firmware does access LocalPolicy from another container in the internal SSD, and there’s always the NVRAM, but there’s no access to anything in /Library, including the many property lists there. This also means that processes running before the Data volume is unlocked and mounted can’t write to storage.
Around 10-15 seconds after the start of booting, the login window is displayed, ready for the user to enter their password. Once that has been entered, there’s a watershed moment: 30.845097 com.apple.loginwindow Attempting to unlock the data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.883172 "AppleSEPKeyStore":3814:0: Sending notification for volume [UUID] unlocked (action 1, handle -842987934)
30.885459 com.apple.login volume <LFVolume: 0x6000001b8e40: [UUID]: Data> was unlocked
30.886129 com.apple.loginwindow Unlocked data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.886154 com.apple.loginwindow FileVault volume unlocked, allow authorization
30.887562 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:439: Authorization was successful
30.887587 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:447: logging in user hoakley
The times on those entries were deliberately delayed, as I pressed the Return key for password entry after 30 seconds had elapsed, a good 10 seconds later than I could have done so.
Shortly after that, the kernel manager shuts down, a great many kernel space processes are handed over to continue in userspace, and you’ll then see the kernel report userspace boot
Before the Data volume is unlocked, log entries are frequent, but hardly a torrent, at around 1,000 per second, and more than 25% of them are written by the kernel. Once the kernel has booted userspace and the Data volume is accessible, log entries are written far more frequently, at an average rate of 5,000 per second, often even higher, with less than 10% of them coming from the kernel.
Phase summary
Boot ROM, entering DFU mode or handing over to
Low-Level Bootloader (LLB) and iBoot (Stage 2) firmware, without log entries, handing over to
In the last few months I have had reports from several whose Macs have experienced a “SEP Panic” rather than a regular kernel panic. Although the immediate effects are the same, and my previous advice on how to deal with a kernel panic still applies, this article looks in more detail at what should be exceedingly rare events.
Essentials
If your Mac restarts or shuts down spontaneously, or ‘freezes’ for you to force it to shut down, chances are that was a kernel panic. When it starts up again, look out for the dialog inviting you to send a report to Apple. Expand that so you can see the panic log, copy and paste that into a text document, and save it. That’s the only record you have of that report, and that provides valuable clues as to what went wrong and how you might go about fixing it.
Apple will not contact you in response to sending the panic log. If you want advice or assistance about your Mac, contact Apple Support, and ensure you have your copy of the panic log ready, as they’ll need to see it.
Secure enclave
No matter how secure you try to make an operating system, if its most precious secrets are being processed by the main CPU cores, an attacker will find a way to access them. The proven solution to this is to build in a separate part of the chip with its own processor, and isolate that from everything else – a secure enclave, with its own secure enclave processor, SEP, as patented by Apple 13 years ago.
Two Mac architectures have secure enclaves and SEPs: Intel Macs with T2 (and T1) chips, where the SEP is in the T2/T1, and Apple silicon Macs, where the SEP is an integral part of the chip. These handle several different security features, including biometrics in Touch ID, management of secure encryption keys including those for FileVault, and performing encryption and decryption for the internal SSD.
The SEP runs its own operating system, sepOS, thought to be a derivative of L4, and communicates with the rest of the chip using mailboxes. When the CPU needs something from the SEP, it posts a message in the SEP mailbox, then retrieves the response when the SEP has processed that request.
What could possibly go wrong?
Like all processors, the SEP can hit problems that it can only manage by a reset, and those will result in it panicking, which in turn provokes the kernel running on the CPU to panic. Those problems can result from anything from a hardware fault to a bug in sepOS.
The SEP in a T2 chip is also known to be vulnerable to some exploits including blackbird, which can be used to ‘jailbreak’ a device using checkra1n or with malicious intent.
Reading the SEP panic log
When a kernel panic is the result of a SEP panic, the panic log is different from normal, and contains considerable detail about the SEP and what went wrong with it. As usual, though, much of that information is cryptic to say the least.
The first line in the panic log confirms that the panic originated in the SEP panic(cpu 1 caller 0xfffffe001f55e344): SEP Panic: […]
You’re then given the version of sepOS Root task vers: AppleSEPOS-2772.140.4
Unfortunately, further down it disclaims knowledge of that Firmware type: UNKNOWN SEPOS
The status of the SEP’s mailboxes are given Mailbox status:
IDLE_STATUS: 0x00000008
INBOX0_CTRL: 0x00105601
OUTBOX0_CTRL: 0x00023301
and Mailbox entries:
Unavailable
Mailbox queue pointers: […]
This is confirmed as a panic Debugger message: panic
The version of macOS is given by build number, with details of the kernel running on the CPU OS version: 24G90
Kernel version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
For a T2 chip, the kernel version given should be for a T8010 root:xnu-11417.140.69~1/RELEASE_ARM64_T8010
Apple silicon Macs should then confirm their iBoot versions, first the LLB (Stage 1) then iBoot Stage 2, and whether Secure Boot was used iBoot version: iBoot-11881.140.96
iBoot Stage 2 version: iBoot-11881.140.96
secure boot?: YES
T2 SEPs don’t normally give an iBoot Stage 2 version, but provide information about the Intel (x86) host iBoot Stage 2 version:
secure boot?: YES
roots installed: 0
x86 EFI Boot State: 0xe
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0x5
x86 Previous Power Transitions: 0x20002000200
PCIeUp link state: 0x94721611
Information is provided about the task running on the CPU, which should normally be the kernel Panicked task 0xfffffe1fb0037248: 0 pages, 654 threads: pid 0: kernel_task
Towards the end of the panic log are details about kernel extensions. In SEP panics, that includes the SEP Manager Kernel Extensions in backtrace:
com.apple.driver.AppleSEPManager(1.0.1)[UUID]@0xfffffe001f5366e0->0xfffffe001f566a63
and last started kext at 242997189818: com.apple.iokit.SCSITaskUserClient 500.120.2 (addr 0xfffffe001ce0f6a0, size 2206)
loaded kexts:
In the list of loaded kernel extensions that follows, ensure there are no third-party entries, unless your Mac is expected to load them.
Actions
Although you should take a SEP panic seriously, there’s no need to panic yourself. This doesn’t mean that your Mac’s SEP has died, has been attacked by malware, or has released all the secrets it protects. A single panic in isolation could well just be chance, and not indicative of anything serious.
Provided that your Mac starts up correctly and then runs normally, your only essential task is to ensure that you capture and keep a copy of the panic log. If you wish, you can run hardware Diagnostics, but I doubt whether that performs any specific test intended to detect problems in the SEP. If you have potentially problematic peripherals, or any third-party kernel extensions, then you should take the hint and try to eliminate them.
If your Mac suffers any further kernel panics, capture their panic logs, and contact Apple Support with those to hand. Alternatively, book your Mac into an Apple store or authorised service provider for them to check it out for you.
Summary
SEP panics are exceedingly rare, but are readily identified from the first line of the panic log.
Ensure you copy and save a copy of the panic log.
Much of the panic log will appear meaningless, but there is some information about version numbers and kernel extensions that may be helpful.
Follow the normal recommendations, considering hardware diagnostics, and updating/removing potentially troublesome peripherals and third-party kernel extensions.
If there are any further panics, capture those and obtain support from Apple.
Sometimes even the best-kept Macs start acting strangely, and no matter what you try, you can’t put your finger on the problem, and can’t make it go away. This article suggests some potentially radical solutions that should address the most intransigent of problems in Apple silicon Macs.
Hardware?
If the problem lies in a peripheral, or the Mac’s hardware, then everything else is doomed to fail. Start by disconnecting all non-essential peripherals, and if that doesn’t help, run hardware diagnostics from Recovery mode. Those don’t always catch problems, particularly in their early stages, so if you’re not convinced that your Mac is sound and healthy, book it in for your nearest Apple store or authorised service provider to run their more extensive tests.
To run hardware diagnostics in an Apple silicon Mac, start it up in Recovery by pressing its Power button until it displays that it’s loading options, then in the initial Options screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed, so a good Wi-Fi connection is important. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.
What to reinstall?
At this stage with an Intel Mac, you’d be considering performing a clean reinstall of macOS, maybe even trying to revert to an older version that didn’t show the problem. Although you can still try that in Recovery mode, Apple silicon Macs have a better and more thorough option, to Restore the whole of your Mac’s firmware and macOS. This is performed by putting it into DFU mode, connected to another Mac (either architecture) running a recent version of macOS, and performing the Restore from there.
Apple provides detailed instructions for you to do this yourself, provided you have the necessary second Mac and cable. If you don’t have those, you should be able to get this performed free of charge at an Apple store, or by an authorised service provider.
The cable used mustn’t be Thunderbolt, but plain USB-C. That’s because DFU mode doesn’t support Thunderbolt or its cable. Connect that to the designated DFU port on the Mac you’re going to Restore. That can be found in Apple’s note, or in Mactracker.
You used to have to run Apple Configurator on the second Mac, but this can now be handled through the Finder, where it’s usually the more reliable. Follow Apple’s instructions to Restore the current version of the firmware and macOS, or you can download an IPSW image file for most previous versions through the links on Mr. Macintosh’s site.
Before performing this, you must make a full backup of your Mac’s internal storage, as the Restore process wipes it clean, and you’ll want to restore from that backup afterwards. As this process is going to wipe your Mac, you’ll also want to check through third-party apps and subscriptions that need to be signed out or transferred. Check carefully through the Applications folder to ensure that you haven’t forgotten any that are still valid. Among those is the need to deauthorise your old Mac for Apple media, something you should do using one of its media apps such as Music or TV.
Revive or Restore?
Apple advises trying to revive your Mac first, as it’s a briefer procedure and doesn’t wipe the whole of the Mac’s internal storage. However, if you’re trying to fix a deep-seated problem, only a full Restore will do.
What does a Restore do?
Internal storage in Apple silicon Macs contains additional partitions/containers to those found in Intel Macs or on external boot disks. These store the firmware and other components used early during the boot process, as part of Secure Boot. A ‘clean’ reinstall only replaces the boot volume group, the Signed System Volume (SSV) and Data volume, while a Restore in DFU mode wipes everything including the firmware, and replaces it with fresh copies from the IPSW file.
The end result is that your Mac is running the firmware to match the version of macOS installed, just as it would have been from the factory. It then has to be personalised and reconfigured from scratch once it’s started up. Nothing from its old firmware, macOS or Data volume is left, even the NVRAM, stored in NOR Flash memory, is reset.
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.
By now your Mac should have the latest macOS update installed, and be running the current firmware. This article takes stock of where EFI, T2 and Apple silicon firmware are now, and where they’re heading with the forthcoming release of macOS 26 Tahoe in a month or two.
For many years, the only way your Mac will have its firmware updated is when macOS or one of its updates is installed on it. There is one significant exception to that, in Apple silicon Macs, whose firmware will be completely replaced when it’s put into DFU mode and restored from an IPSW file.
Each macOS update or full installer comes with the firmware current at the time Apple built it. So if your Mac is still running macOS 12.7.6 Monterey and has never installed any later version, it will have the firmware that came with that, such as iBoot 10151.140.19, or T2 version 2022.140.5.0.0 with iBridge 21.16.6074.0.0,0.
Note that firmware is updated whether macOS is installed or updated on the internal storage, or on an external disk. So if your Mac’s internal SSD is still running 12.7.6, but it has been used to update Ventura to 13.7.7 on an external SSD, then it will have the firmware brought in that version of Ventura, rather than that for Monterey. That doesn’t of course apply to macOS installed in any virtual machines, as they can’t update the host firmware.
Intel Macs without T2 chips
All these models appear to have reached the end of their EFI firmware updates, with the versions shown. iMac:
iMac18,1 529.140.2.0.0
iMac18,3 529.140.2.0.0
iMac19,1 2075.100.3.0.3
MacBook:
MacBook10,1 529.140.2.0.0
MacBook Pro:
MacBookPro14,1 529.140.2.0.0
MacBookPro14,2 529.140.2.0.0
MacBookPro14,3 529.140.2.0.0
All those date from 23 June 2024, apart from that for the iMac19,1, whose latest firmware is from March 2025. Although the latter could still be updated in a security update to Sonoma or Sequoia, that now looks increasingly unlikely.
Intel Macs with T2 chips
The current EFI version is 2075.140.4.0.0 and iBridge is 22.16.16083.0.0,0, and those are likely to continue to be updated over the coming year. However, T2 models still running macOS Ventura are likely to stay there, unless Apple releases one final extra update. To ensure that your T2 Mac continues to get firmware updates, it now needs to be running Sonoma or later.
Apple silicon Macs
The current iBoot version is 11881.140.96, and that is sure to see a substantial update with the release of macOS 26.0, and in the simultaneous security updates for Sequoia and Sonoma. However, any Apple silicon Mac still running Ventura or earlier will be running an older version of iBoot that it can’t update, unless it installs or updates a more recent macOS in another boot volume group, such as on an external disk.
Apple Studio Display
Display firmware remains at version 17.0 (build 21A329) as it was when updated with macOS Sonoma nearly two years ago in September 2023. Although there’s no sign of any update with the beta-test versions of Tahoe, maybe it’s likely that this will be updated with macOS 26.0 and its associated security updates.
Check
The currently installed firmware version is displayed in System Information, by selecting the Hardware item at the top left. It’s also checked against the current version in SilentKnight. However, in recent Mac models with T2 or Apple silicon chips it’s most unlikely to differ from that brought with the latest version of macOS that Mac has installed or updated. Macs without T2 chips were less reliable, and some older models often failed to update when expected. Thankfully that’s now a problem of the past. If there’s one thing you should be able to trust it’s firmware updating.
Login
