Almost exactly a year after it released its first Macs featuring chips in the M3 family, Apple has replaced those with the first M4 models. Benchmarkers and core-counters are now busy trying to understand how these will change our Macs over the coming year or so. Before I reveal which model I have ordered, I’ll try to explain how these change the Mac landscape, concentrating primarily on CPU performance.

CPU cores

CPUs in the first two families, M1 and M2, came in two main designs, a Base variant with 4 Performance and 4 Efficiency cores, and a Pro/Max with 8 P and 2 or 4 E cores, that was doubled-up to make the Ultra something of a beast with its 16 P and 4 or 8 E cores. Last year Apple introduced three designs: the M3 Base has the same 4 P and 4 E CPU core configuration as in the M1 and M2 before it, but its Pro and Max variants are more distinct, with 6 P and 6 E in the Pro, and 10-12 P and 4 E cores in the Max. The M4 family changes this again, improving the Base and bringing the Pro and Max variants closer again.

As these are complicated by sub-variants and binned versions, I have brought the details together in a table.

I have set the core frequencies of the M4 in italics, as I have yet to confirm them, and there’s some confusion whether the maximum frequency of the P core is 4.3 or 4.4 GHz.

Each family of CPU cores has successively improved in-core performance, but the greatest changes are the result of increasing maximum core frequencies and core numbers. One crude but practical way to compare them is to total the maximum core frequencies in GHz for all the cores. Strictly speaking, this should take into account differences in processing units between P and E cores, but that also appears to have changed with each family, and is hard to compare. In the table, columns giving Σfn are therefore simply calculated as
(max P core frequency x P core count) + (max E core frequency x E core count)

Plotting those sum core frequencies by variant for each of the four families provides some interesting insights.

Here, each bar represents the sum core frequency of each full-spec variant. Those are grouped by the variant type (Base, Pro, Max, Ultra), and within those in family order (M1 purple, M2 pale blue, M3 dark blue, M4 red). Many trends are obvious, from the relatively low performance expected of the M1 family, except the Ultra, and the changes between families, for example the marked differences in the M4 Pro, and the M3 Max, against their immediate predecessors.

Sum core frequencies fall into three classes: 20-30, 35-45, and greater than 55 GHz. Three of the four chips in the M1 family are in the lowest of those, with only the M1 Ultra reaching the highest. The M4 is the first Base variant to reach the middle class, thanks in part to its additional two E cores. Two of the M4 variants (Pro and Max) have already reached the highest class, and any M4 Ultra would reach far above the top of the chart at 128 GHz.

Real-world performance will inevitably differ, and vary according to benchmark and app used for comparison. Although single-core performance has improved steadily, apps that only run in a single thread and can’t take advantage of multiple cores are likely to show little if any difference between variants in each family.

Game Mode is also of interest for those considering the two versions of the M4 Base, with 4 or 6 E cores. This is because that mode dedicates the E cores, together with the GPU, to the game being played. It’s likely that games that are more CPU-bound will perform significantly better on the six E cores of the 10-Core version of the iMac, which also comes with a 10-core GPU and four Thunderbolt 4 ports.

Memory and GPU

Memory bandwidth is also important, although for most apps we should assume that Apple’s engineers match that with likely demand from CPU, GPU, neural engine, and other parts of the chip. There will always be some threads that are more memory-bound, whose performance will be more dependant on memory bandwidth than CPU or GPU cores.

Although Apple claims successive improvements in GPU performance, the range in GPU cores has started at 8 and attained 32-40 in Max chips. Where the Max variants come into their own is support for multiple high-res displays, and challenging video editing and processing.

Thunderbolt and USB 3

The other big difference in these Macs is support for the new Thunderbolt 5 standard, available only in models with M4 Pro or M4 Max chips; Base variants still only support Thunderbolt 4. Although there are currently almost no Thunderbolt 5 peripherals available apart from an abundant supply of expensive cables, by the end of this year there should be at least one range of SSDs and one dock shipping.

As ever with claimed Thunderbolt performance, figures given don’t tell the whole story. Although both TB4 and USB4 claim ‘up to’ 40 Gb/s transfer rates, in practice external SSD performance is significantly different, with Thunderbolt topping out at about 3 GB/s and USB4 reaching up to 3.4 GB/s. In practice, TB5 won’t deliver the whole of its claimed maximum of 120 Gb/s to a single storage device, and current reports are that will only achieve disk transfers at 6 GB/s, or twice TB4. However, in use that’s close to the expected performance of internal SSDs in Apple silicon Macs, and should make booting from a TB5 external SSD almost indistinguishable in terms of speed.

As far as external ports go, this widens the gap between the M4 Pro Mac mini’s three TB5 ports, which should now deliver 3.4 GB/s over USB4 or 6 GB/s over TB5, and its two USB-C ports that are still restricted to USB 3.2 Gen 2 at 10 Gb/s, equating to 1 GB/s, the same as in M1 models from four years ago.

My choice

With a couple of T2 Macs and a MacBook Pro M3 Pro, I’ve been looking to replace my original Mac Studio M1 Max. As it looks likely that an M4 version of the Studio won’t be announced until well into next year, I’m taking the opportunity to shrink its already modest size to that of a new Mac mini. What better choice than an M4 Pro with 10 P and 4 E cores and a 20-core GPU, and the optional 10 Gb Ethernet? I seldom use the fourth Thunderbolt port on the Studio, and have already ordered a Kensington dock to deliver three TB5 ports from one on the Mac, and I’m sure it will drive my Studio Display every bit as well as the Studio has done.

If you have also been tempted by one of the new Mac minis, I was astonished to discover that three-year AppleCare+ for it costs less than £100, that’s two-thirds of the price that I pay each year for AppleCare+ on my MacBook Pro.

I look forward to diving deep into both my new Mac and Thunderbolt 5 in the coming weeks.

One of the novel features in the original Finder in Classic Mac OS was the use of distinctive icons for different types of document in an extensible scheme.

Every file had its type and creator codes, each consisting of four single-byte characters. The Desktop databases contained indexes to those, to enable the Finder to display the appropriate icon for a text document of type TEXT created by an app with the creator code of ttxt, SimpleText, for instance.

Apps provided a custom icon in their Resource fork for each type of document they supported. Periodically, those Desktop databases became broken, and documents lost their custom icons. The solution was to rebuild those Desktop databases from the data in each app’s Resources, a procedure that every Mac user became only too familiar with.

At some stage, perhaps in System 6 of 1988, or System 7 of 1991, document icons such as images could be displayed as miniatures or thumbnails instead. This was accomplished by apps creating that file’s thumbnail and saving it as an ICN# resource in the file’s Resource fork. Amazingly, this still works in Sequoia, where I pasted a prepared Resource fork into a Zip file to give it an inappropriate thumbnail.

The raw Resource fork is shown below in xattred as a com.apple.ResourceFork extended attribute.

Initially, Mac OS X continued a similar system, including custom thumbnails, until Apple introduced Quick Look in Mac OS X 10.5 Leopard, in 2007. This came with built-in support for a wide range of common document types, extending to QuickTime media including audio and video. One curious omission at first was that animated GIFs weren’t supported as animations until OS X 10.7.

Display of Thumbnails used the QuickLook framework documented here. This enabled third-parties to extend coverage to their own document types using QuickLook generators with the extension .qlgenerator. Initially, they were installed into /Library/QuickLook from each app bundle.

Normally, when QuickLook generated a Thumbnail or Preview, that was stored in its cache database kept in NSTemporaryDirectory in the path C/com.apple.QuickLook.thumbnailcache/. Those could give revealing insights into images and other documents accessed recently, and Wojciech Regula and Patrick Wardle discovered that, in High Sierra and earlier, it was easy for malicious software to examine that cache. Apple addressed that in macOS 10.14 Mojave by making the cache completely inaccessible.

In-memory caching of Thumbnails has also proved controversial in more recent versions of macOS. To deliver smooth scrolling of Thumbnails in the Finder’s Gallery views in particular, the Finder has taken to caching them in memory for up to two days, sometimes using several GB in the process. That can readily be mistaken for a memory leak, until those cached Thumbnails are finally flushed.

I described how QuickLook Thumbnails worked in early 2019, in the days before the SSV.

When you select a document in the Finder, a dialog, or somewhere else where you expect its icon to be shown, the Finder passes details of the document path and its type (UTI) to IconServices, to fetch the appropriate icon. This calls on its main service, iconservicesd in /System/Library/CoreServices, to check its icon cache.

Although the main icon store is locked away in /Library/Caches/com.apple.iconservices.store, there’s additional data in a folder on a path based on /private/var/folders/…/C/com.apple.iconservices, where … is an unreadable alphanumeric name. For icons used in the Dock, their cache is at /private/var/folders/…/C/com.apple.dock.iconcache. If the icon should be replaced by a QuickLook Thumbnail, such as in a Finder column view, QuickLook is asked to provide that thumbnail. That in turn may be cached in its protected cache at /private/var/folders/…/C/com.apple.QuickLook.thumbnailcache.

QuickLook then relies on there being an appropriate qlgenerator to create a thumbnail of that document type; if the qlgenerator is flawed or can’t cope with the document’s contents, that could easily fall over. For example, if you renamed a text file with a .jpeg extension so that macOS considered it was a JPEG image, the bundled qlgenerator might have simply resulted in the display of a busy spinner, rather than resolving to a generic JPEG document icon. IconServices should then deliver the appropriate icon back to the Finder to display it.

In macOS 10.15 Catalina (2019), Apple started replacing this system with a new framework named QuickLook Thumbnailing, documented here. That replaces qlgenerators with QuickLook preview extensions, in particular Thumbnail Extensions, as explained to developers at WWDC in 2019.

macOS 15.0 Sequoia has finally removed support for qlgenerators. That has resulted in the unfortunate loss of custom Thumbnails and Previews for document types of third-party apps that are still reliant on qlgenerators, and haven’t yet got round to providing equivalent app extensions. It’s almost as if the Desktop databases need to be rebuilt again.

Apple has made great play over the privacy provided in its new AI tools. If you’ve just updated your Apple silicon Mac to Sequoia 15.1 and are wondering how you can check on this for Writing Tools, this article explains how.

When running on a capable Mac, with an M-series chip, macOS captures details of all AI use in its Apple Intelligence Report (AIR). Control and access that from its new entry in Privacy & Security settings, where you’ll find it towards the end, just above the final Security section. Open that, and you’ll see you can set the Report Duration to 15 minutes, 7 days, or turn it off altogether. As report sizes can grow quickly with a little use of Writing Tools, I suggest you start off with 15 minutes, or you might get overwhelmed.

When you want to browse a report, simply click on the button to Export Activity, and save the AIR report.

Apple Intelligence Reports are written out to JSON files that can be viewed using a text editor if you don’t have a specialist JSON editor. They’re usually bulky, and much of their content may be encoded binary that’s of little meaningful use. However, at the start you’ll see a series of modelRequests.

Each modelRequest begins with the timestamp of the request, given in decimal seconds since 1970. That’s followed by a UUID, information on the prompt template used, and shortly after that is the text that was extracted and used by Writing Tools. For longer passages of text, you may see that it’s divided up into a series of shorter sections that match the paragraphs given in a summary.

After that input text, the language localisation is given, currently en_US as other variants and languages won’t be available until macOS 15.2 later this year. Next, the response is provided, as inserted into the Writing Tools or text window. That section ends with:

• model, the name of the AI model used, such as com.apple.fm.language.instruct_server_v1.text_summarizer, and the version.
• clientIdentifier, such as com.apple.WritingTools.xpc.WritingToolsViewService for normal use of Writing Tools in an app.
• executionEnvironment, currently expected to be PrivateCloudCompute, which tells you where the AI processing took place.

After the list of modelRequests, you’ll probably see a long series of privateCloudComputeRequests full of incomprehensible data for sepAttestations and provisioningCertificateChains, part of the validation information for use of PrivateCloudCompute. If this all seems a little long-winded, try looking in the logs when Writing Tools are in use!

I’m very grateful to Tim, who has drawn my attention to these reports, and points out that use of PrivateCloudCompute appears confined to macOS at the moment. A similar report is also available for iOS 18.1, but iPhones don’t appear to rely on PrivateCloudCompute in the same way.

We must remember that, while Apple considers Writing Tools now ready for general use, it’s still officially a beta-release, and over the coming months is likely to undergo significant change. This poses the question of whether Writing Tools will run on-device in the future, something only Apple can answer. What appears to happen at present is that the only local processing that takes place is tokenisation of text to prepare it for remote processing using Apple’s PrivateCloudCompute service, which actually performs the heavy lifting before returning its results to the Mac. However, macOS also appears to wake up the slumbering Neural Engine (ANE) for most Writing Tools services. Why that happens remains a mystery.

If you want to watch progress as AI features develop in macOS, you may find Apple Intelligence Reports a useful way to track that. If you do come across entries that seem to have used on-device services instead of PrivateCloudCompute, please let us know.

Early this coming week those fortunate enough to have an Apple silicon Mac will be able to update Sequoia to version 15.1 and try out Writing Tools at last. I’ve been testing and using them since the first beta of 15.1 back when the daylight lasted well into the night. I’ve been surprised at how lukewarm some have been at their arrival, particularly as most of those comments have come from those who make a living from their writing.

Perhaps the best way to show what Writing Tools can do is with an example, using the text from yesterday’s article A brief history of Mac firmware, a little over a thousand fairly technical words. I concentrate here on Writing Tools’ summary modes rather than its rewriting features, although they’re also thoroughly sound and useful in the right context.

Summary

Producing a succinct single paragraph summary is a challenge for even the most literate of humans. I’m impressed with Writing Tools’ 62 word offering of:
Mac firmware has undergone significant changes, from the Macintosh ROM in Classic Macs to Open Firmware in PowerPC models and EFI in Intel Macs. EFI, later evolving to UEFI, provides hardware access and boot services, while Apple silicon Macs employ a verified chain of trust for enhanced security. Firmware updates are now integrated into macOS installers and updaters, ensuring security and accessibility.

Key points

With so much information in the original, a key point summary should provide a better reflection of my original thousand words. Rather than reproducing the full 250 words generated by Writing Tools, here’s an excerpt covering one of the more challenging sections:

• Firmware Security Issue: Researchers demonstrated proof-of-concept attacks on Mac firmware, highlighting potential vulnerabilities.
• Firmware Update Policy Change: Apple transitioned from separate firmware updates to delivering them through system upgrades and updates.
• Firmware Security Concern: In 2017, Duo Labs researchers discovered many Macs running outdated firmware, raising security concerns.
• Apple’s Response: Apple hired security researchers and developed eficheck, a tool to check and report firmware versions to Apple.

I don’t think I could better that.

List

The third type of summary suitable for that article is a detailed list. This strips everything else out to leave terse factual sentences. For the whole text, it reduces to 833 words, a reflection on its already dense information. You’re unlikely to want to use this with longer passages, but here’s the same section given as key points above:

• In March 2015, two security researchers from LegbaCore demonstrated proof-of-concept attacks on the BIOS of several computers.
• The attacks could have been used to implant malicious code.
• Later that year, Kovah and Trammell Hudson turned their attention to Macs.
• They demonstrated a firmware worm named Thunderstrike 2.
• For the first nine years of Intel Macs, Apple had provided EFI firmware updates separately from updates to OS X.
• In 2015, Apple changed the way that it supplied firmware, delivering it only as part of system upgrades and updates.
• Although older separate firmware updates are still available, those were the last.
• In 2017, Rich Smith and Pepijn Bruienne of Duo Labs discovered that many Macs were running outdated firmware.
• Their concern was about the security risk posed by outdated firmware.
• Apple had already been busy hiring Xeno Kovah and Corey Kallenberg who started work there in November 2015, and Nikolaj Schlej, another firmware security researcher, who joined them the following August.
• They developed a new tool eficheck, released in High Sierra on 25 September 2017.
• eficheck checked current firmware against a local database of versions known to be ‘good’, and with the user’s permission sent a report to Apple in the event that it found discrepancies.

Table

The fourth summary option is to generate a table. Unfortunately, my example wouldn’t produce a useful table without substantial additional knowledge. However, I’ve found this useful on long passages from fiction, where it can summarise relationships between different characters, and similar tasks.

On device and on target

Once Sequoia 15.1 has been released and I’ve had a chance to explore the internals of Writing Tools further, I’ll look at its processing and energy costs. Two important features distinguish it from other contemporary AI tools: all data remains on-device throughout, and it’s primarily using your text rather than a large language model built from vast quantities of text garnered from around the internet.

Privacy doesn’t generally worry me particularly, as much of what I write on Macs is destined in some way or another to be published, whether it’s in an article here, one in the magazines that I write for, or source code that will be built into apps. However, I do take exception to others making money out of my labours without my express consent, so I’ll generally be only too happy to keep my AI on-device.

I also think it’s important to draw a clear distinction between what Writing Tools offers, and the likes of ChatGPT. Now that I’m testing Sequoia 15.2 beta, I have been looking at that contrast. While you can’t ask Writing Tools questions (why would you want to when you have the whole text and its summaries?), I thought I’d see how ChatGPT answered one of my stock test questions for AI: what is the SSV?

At my first asking, ChatGPT didn’t have sufficient context, and told me that it’s a side-by-side vehicle, so I refined my question to what is the SSV in macOS?

Although much of its answer was correct and informative, the second sentence stated with complete confidence that the SSV was introduced in macOS Catalina, which is of course completely incorrect, as Catalina has a read-only System volume but not a Signed System Volume as was introduced in Big Sur. But you’d only spot that serious factual error if you already knew the answer.

Give me Writing Tools and my own fact-checking, thank you.

Earlier this week, I explained how the Signed System Volume (SSV), Data volume and cryptexes are integrated into the boot volume group, to support a secure boot process. This article outlines how modern Macs tackle the problem of booting securely.

The aim of a secure boot process is to ensure that all steps from the Boot ROM to the operating system are verified against any unauthorised change, and the code loaded and run is as intended. A simple operating system might achieve that by running only code contained in a boot ROM, but that’s woefully inadequate for any modern general-purpose operating system such as macOS, which also needs to be updated and upgraded during a Mac’s lifetime. Thus the great bulk of macOS has to be loaded and run from mutable storage, now SSDs. Those and a great deal else require specialised cores, with their own firmware, and features like the Secure Enclave. This is achieved in a cascade, where each step provides access to more of the Mac’s hardware, until many of Sequoia’s 670 kernel extensions are loaded and ready.

Intel Mac without T2 chip

Older models of Macs without a T2 chip follow a classic and insecure process when booting. Their Boot ROM loads UEFI firmware, and that in turn loads boot.efi, the macOS booter, without performing any verification. The macOS booter then loads the prelinked kernel from disk, again without verifying it. When the kernel opens the SSV, any checks on that can only be cursory, as Recovery for these Macs doesn’t offer controls in the form of a Startup Security Utility.

In High Sierra (2017), Apple introduced eficheck to periodically run checks on the version and integrity of UEFI firmware, although that doesn’t take place during the boot process, and was discontinued in macOS 14 Sonoma.

Intel Mac with T2 chip

These are the first Macs to support Secure Boot, thanks to their T2 chip, which is based on a variant of Apple’s A10 chip, dating back to 2016; the first model featuring a T2 chip was released at the end of 2017. As shown in the diagram at the end of this section, these Macs start their boot process with their Boot ROM verifying the iBoot ‘firmware’ for the T2 chip. That in turn verifies the kernel and its extensions for the T2, and that verifies the UEFI for the Intel side of the Mac.

Booting the Intel chipset proceeds similarly to older Intel Macs, but each step verifies the code to be run by the next, until its immutable kernel is loaded and boots the rest of macOS. Early in that stage, the kernel verifies the SSV before proceeding any further. Failure in any of the verifications halts the boot process, if you’re lucky in Recovery or T2 DFU mode.

This diagram compares boot processes in the three modern Mac architectures.

Apple silicon Mac

In the absence of any Intel chipset, Apple decided to implement its own Secure Boot, although there are options that could have allowed it to remain with UEFI. M-series chips tackle this in four steps:

1. Boot ROM, which verifies the Low Level Bootloader (LLB).
2. LLB, sometimes described as the first stage, concerned with loading and booting some auxiliary cores, security policy, and verifying the second stage, iBoot.
3. iBoot, which continues validations and verifications, including signatures and root hash of the SSV, before handing over to the kernel.
4. The kernel, which boots macOS.

Apple silicon chips contain many specialist cores responsible for implementing hardware features such as Thunderbolt. Firmware for each of those has to be verified and loaded to boot those cores, a task performed by LLB and iBoot.

Security policy for each boot volume group is set in its LocalPolicy, and has to be loaded and validated by LLB. The SSV is verified by iBoot prior to handing over to the kernel, to ensure the file system has been checked before it’s mounted.

When running in Full Security, the only kernel extensions to be loaded are those supplied in macOS, forming the standard Boot Kernel Collection. If the user has set that boot volume group to Reduced Security and opted for it to load third-party kernel extensions, those are contained in the Auxiliary Kernel Collection, and validated by iBoot. Once the kernel and extensions collection have been loaded, the latter is locked in memory with SCIP (System Coprocessor Integrity Protection) prior to iBoot handing over to the kernel to boot.

As with T2 Macs, any failure of verification during Secure Boot should leave that Mac either in Recovery mode, or in DFU mode ready to be connected to another Mac for its firmware to be refreshed, or restored from scratch.

External boot disks

T2 Secure Boot doesn’t support booting from an external disk, which is only allowed by reducing the security setting in Startup Security Utility. When designing its M-series Macs, Apple wanted them to benefit from Secure Boot when starting up from an external disk, and incorporated this into its design.

This is implemented by the Mac always starting the boot process internally, with the LLB and iBoot being run from internal storage. Bootable external disks must have an ‘owner’ to associate them with a LocalPolicy loaded by LLB. That enables iBoot to validate the Boot Kernel Collection, SSV and other components in the external boot volume group, then to hand over to its kernel to boot macOS from that disk, instead of the internal SSD.

It took a few versions of Big Sur before this worked reliably, but this should now be robust, provided that it’s set up correctly by the user. However, it’s often incorrectly claimed that Apple silicon Macs can only start up from external disks by reducing security.

Further reading

Apple’s Platform Security Guide:
Boot process for an Intel-based Mac
Boot process for a Mac with Apple silicon
Signed system volume security

This blog:
Booting an M1 Mac from hardware to kexts: 1 Hardware
Booting an M1 Mac from hardware to kexts: 2 LLB and iBoot
Booting an M1 Mac from hardware to kexts: 3 XNU, the kernel
Make a Ventura bootable external disk for an Apple silicon Mac
Booting macOS on Apple silicon: LocalPolicy
Ownership of Apple silicon Macs matters: how it can stop external bootable disks
Booting macOS on Apple silicon: Multiple boot disks

Encrypting all your data didn’t become a thing until well after the first release of Mac OS X. Even then, the system provided little support, and most of us who wanted to secure private data relied on third-party products like PGP (Pretty Good Privacy).

FileVault 1

Apple released the first version of FileVault, now normally referred to as FileVault 1 or Legacy FileVault, in Mac OS X 10.3 Panther in 2003. Initially, that only encrypted a user’s Home folder into a sparse disk image, then in 10.5 Leopard it started using sparse bundles instead. These caused problems with Time Machine backup when it too arrived in Leopard, and proved so easy to crack that in 2006 Jacob Appelbaum and Ralf-Philipp Weinmann released a tool, VileFault, to decrypt FileVault disk images.

FileVault 1 was controlled in the Security pane of System Preferences, shown here in 2004.

Each new user added in the Accounts pane could have their Home folder stored in an encrypted disk image. Encryption keys were based on the user’s password, with a master password set for all accounts on the same Mac.

FileVault 2

FileVault 2 was introduced in Mac OS X 10.7 Lion in 2011, and at last provided whole-volume encryption based on the user password. Encryption was performed using the XTS-AES mode of AES with a 256-bit key, by the CPU. At that time, more recent Intel processors had instructions to make this easier and quicker, but all data written to an encrypted volume had to be encrypted before it was written to disk, and all data read from it had to be decrypted before it could be used. This imposed significant overhead of around 3%, which was more noticeable on slower storage such as hard disks, and with slower Macs.

Apple didn’t implement this by modifying the HFS+ file system to add support for encryption, but by adding encryption support to CoreStorage, the logical volume manager. In theory this would have enabled it to encrypt other file systems, but I don’t think that was ever done.

Turning FileVault on and off was quite a pain, as the whole volume had to be encrypted or decrypted in the background, a process that could take many hours or even days. Most users tried to avoid doing this too often as a result so, while FileVault 2 was secure and effective, it wasn’t as widely used as it should have been.

These screenshots step through the process of enabling FileVault in 2017.

Control was in the FileVault tab in System Preferences.

iCloud Recovery was added as an alternative to the original recovery key.

Encryption began following a restart, and then proceeded in the background for however long it took. Shrewd users enabled FileVault when a minimum had been installed to the startup volume, to minimise time taken for encryption.

With a minimal install, it was possible to complete initial encryption in less than an hour. With full systems, it could take days if you were unlucky.

Although FileVault has had a few security glitches, it has done its job well. Perhaps its greatest threat came in the early days of macOS Sierra, when Ulf Frisk developed a simple method for retrieving the FileVault password for any Mac with a Thunderbolt port. An attacker could connect a special Thunderbolt device to a sleeping or locked Mac, force a restart, then read the password off within 30 seconds. This exploited a vulnerability in the handling of DMA, and was addressed by enabling VT-d in EFI, in Sierra 10.12.2 and 10.12.4.

Hardware encryption

The next big leap forward came at the end of 2017, with the release of the first Macs with T2 chips, as intermediates on the road to Apple silicon. One of Apple’s goals in T2 and Apple Silicon chips was to make encrypted volumes the default. To achieve that, T2 and M-series chips incorporate secure enclaves and perform encryption and decryption in hardware, rather than using CPU cycles.

The Secure Enclave incorporate the storage controller for the internal SSD, so all data transferred between CPU and SSD passes through an encryption stage in the enclave. When FileVault is disabled, data on protected volumes is still encrypted using a volume encryption key (VEK), in turn protected by a hardware key and a xART key used to protect from replay attacks.

When FileVault is enabled, the same VEK is used, but it’s protected by a key encryption key (KEK), and the user password is required to unwrap that KEK, so protecting the VEK used to perform encryption/decryption. This means that the user can change their password without the volume having to be re-encrypted, and allows the use of special recovery keys in case the user password is lost or forgotten. Keys are only handled in the secure enclave.

Securely erasing an encrypted volume, also performed when ‘erasing all content and settings’, results in the secure enclave deleting its VEK and the xART key, rendering the residual volume data inaccessible even to the secure enclave itself. This ensures that there’s no need to delete or overwrite any residual data from an encrypted volume: once the volume’s encryption key has been deleted, its previous contents are immediately unrecoverable.

Coverage of boot volumes by encryption varies according to the version of macOS. Prior to macOS Catalina, where macOS has a single system volume, the whole of that is encrypted; in Catalina, both System and Data volumes are encrypted; in Big Sur and later, the Signed System Volume (SSV) isn’t encrypted, nor are Recovery volumes, but the Data volume is.

External disks

Hardware encryption and FileVault’s ingenious tricks aren’t available for external disks, but APFS was designed to incorporate software encryption from the outset. As with internal SSDs, the key used to encrypt the volume contents isn’t exposed, but accessed via a series of wrappers, enabling the use of recovery keys if the user password is lost or forgotten. This involves a KEK and VEK in a similar manner to FileVault on internal SSDs. As the file system on the volume is also encrypted, after the KEK and VEK have been unwrapped, the next task in accessing an encrypted volume is to decrypt the file system B-tree using the VEK.

Enabling FileVault has been streamlined in recent years, as shown here in System Settings last year, for an external SSD, thus not using hardware encryption.

FileVault control has moved to Privacy & Security in System Settings.

The choice of iCloud Recovery or a recovery key remains.

Because only the Data volume is now encrypted, enabling FileVault before populating the Home folder allows encryption to be almost instantaneous, on an external disk.

Virtual machines

The most recent enhancement to FileVault protection extends support to Sequoia virtual machines running on Sequoia hosts. Apple hasn’t yet explained how that one works, although I suspect the word exclave is likely to appear in the answer.

If your Mac has a T2 or Apple silicon chip and you haven’t enabled FileVault, then you’re missing one of the Mac’s best features.

This article lists the firmware versions of Macs that have been successfully upgraded to run macOS 15.0 Sequoia.

Apple doesn’t provide an official list of the current firmware versions which should be installed on each model of Mac. That displayed for Intel models uses five decimal numbers separated by dots, e.g 96.0.0.0.0, and is given below. Models with T2 chips consist of two parts, the second covering iBridge in the T2. Apple silicon Macs are different again, and give an iBoot version instead, as they don’t use EFI at all.

Macs still running older versions of macOS are covered by information at:

• this page for Sonoma,
• this page for Ventura,
• this page for Monterey,
• this page for Big Sur,
• this page Catalina,
• this page for High Sierra,
• this page for El Capitan and earlier.

Apple Silicon Macs

The current iBoot version is 11881.1.1.

Intel Macs with T2 chips

The current EFI version is 2069.0.0.0.0 and iBridge is 22.16.10353.0.0,0.

Intel Mac without T2 chip

iMac: iMac19,1 2069.0.0.0.0

Apple Studio Display

The current version remains 17.0 (build 21A329).

T2 chip models:
The iMac Pro, 2019 Mac Pro, iMac 27-inch 2020, 2018 MacBook Pro with Touch Bar (MacBookPro15,1 and 15,2), 2018 Mac mini and 2018 MacBook Air, and their successor models, use a different mechanism for firmware updates, managed by their T2 chips.

How to check your Mac’s firmware version

The simplest way now is to run either of my free tools SilentKnight or LockRattler, available from their 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 which is 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.

Older versions of macOS provided the command tool eficheck at /usr/libexec/firmwarecheckers/eficheck/eficheck to check firmware version and integrity. That was removed from Sonoma. 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 now 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.

(Last updated 23 September 2024)

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

Full Security

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

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

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

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

Changing security

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

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

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

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

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

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

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

Reduced Security

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

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

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

Permissive Security

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

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

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

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

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

External Boot Volumes

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

Summary

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

Reference

Apple’s Platform Security Guide

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

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

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

M1, November 2020

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

M2, July 2022

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

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

M3, November 2023

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

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

M4, May 2024

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

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

M1 to M4

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

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

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

Postscript and non-apologia

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

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

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

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

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

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

System Integrity Protection (SIP) is more than one of the frontline security protections in macOS, it’s a whole family of them, including controls over kernel extensions, protection for NVRAM, and more. This article explains how you can manage different features in SIP using the csrutil command tool, primarily on Apple silicon Macs running Sonoma or Sequoia.

SIP fully enabled

Unless you have very good reason to do otherwise, your Mac should have SIP fully enabled at all times. Utilities like SilentKnight check whether this is so, and if SIP isn’t enabled, you need to fix that as soon as possible. Start your Mac up in Recovery mode, pass through to Options, and open Terminal from the menu there. Enter the following command:
csrutil enable
and then authenticate when prompted. When you have quit Terminal, open Startup Security Utility from the same menu. You should there be able to set your Mac’s security back to full, unless you need to run it at reduced security to load a third-party kernel extension. Once that is set, restart your Mac and it should have returned to normal with SIP fully active, as SilentKnight should confirm.

SIP’s features

Its original and core feature is to protect much of the system from being changed, even by those with root privileges, referred to here as Filesystem Protections, and introduced in El Capitan, in 2015. This is now extensive, and ranges from whole directory trees in the System volume down to individual extended attributes such as com.apple.macl on otherwise unprotected files.

SIP is also responsible for enforcing requirements for the signing and notarization of non-system kernel extensions, and protection of the integrity of the kernel, respectively termed Kext Signing and Kernel Integrity Protections. It imposes restrictions on the use of kernel debuggers in Debugging Restrictions and the DTrace tool in DTrace Restrictions.

Restrictions over changes that can be made to the NVRAM and boot arguments it can apply to the kernel are controlled by SIP’s NVRAM Protections and Boot-arg Restrictions, while the Authenticated Root Requirement should be self-explanatory. Other features of SIP, including the enforcement of the hardened runtime required of notarized apps, are most probably part of its Apple Internal features.

SIP partially disabled

Although there may be occasions when you need to disable SIP completely, those should be extremely rare. In most cases, you should aim to disable only the features that require it, then return SIP to fully enabled as soon afterwards as possible. One good way to remind yourself that you have temporarily disabled SIP is to write that on a sticky note and put that on your Mac’s display until you’ve enabled SIP again. Don’t leave it to memory, as you’re likely to procrastinate and forget.

To disable SIP completely, start up in Recovery, set Startup Security Utility to Reduced Security, and open Terminal. There enter the command
csrutil disable
confirm that’s what you really want to do, and authenticate. When you restart your Mac, SIP should then be disabled, as you can confirm in Terminal using
csrutil status

Finer control is separated out into its individual features:

• Apple Internal, disabled in XNU by CSR_ALLOW_APPLE_INTERNAL, and only disabled when SIP is fully disabled
• Kext Signing, disabled by CSR_ALLOW_UNAPPROVED_KEXTS, abbreviated in csrutil to kext
• Filesystem Protections, disabled by CSR_ALLOW_UNRESTRICTED_FS, abbreviated to fs
• Debugging Restrictions, disabled by CSR_ALLOW_KERNEL_DEBUGGER and CSR_ALLOW_TASK_FOR_PID, abbreviated to debug
• DTrace Restrictions, disabled by CSR_ALLOW_UNRESTRICTED_DTRACE, abbreviated to dtrace
• NVRAM Protections, disabled by CSR_ALLOW_UNRESTRICTED_NVRAM, abbreviated to nvram
• BaseSystem Verification, abbreviated to basesystem
• Boot-arg Restrictions, disabled with nvram
• Kernel Integrity Protections, disabled with kext
• Authenticated Root Requirement, disabled by CSR_ALLOW_UNAUTHENTICATED_ROOT, managed separately using csrutil authenticated-root disable and enable.

To enable SIP with one of these features disabled, use a command of the form
csrutil enable --without [feature]
where [feature] is the abbreviated name of the feature to be disabled, such as kext. Chain those options to disable multiple features, such as
csrutil enable --without kext --without nvram
which enables SIP with the exception of Kext Signing and Kernel Integrity Protections, and NVRAM Protections and Boot-arg Restrictions.

Other configuration flags in XNU that don’t appear to be directly supported by csrutil include: CSR_ALLOW_TASK_FOR_PID, CSR_ALLOW_DEVICE_CONFIGURATION, CSR_ALLOW_ANY_RECOVERY_OS and CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE. Those should be disabled when SIP is fully disabled, though.

Authenticated Root Requirement is managed separately from other SIP controls. To enable it, use the command
csrutil authenticated-root enable
To disable it,
csrutil authenticated-root disable
and to check its status
csrutil authenticated-root status
Note that fully enabling SIP also enables Authenticated Root Requirement.

The following summary table should help you use these complicated options for control of SIP features using csrutil.

To disable a specific feature, use the --without option for that abbreviated feature name, or the authenticated-root disable option. Note that running csrutil enable also enables the Authenticated Root Requirement. If you need to disable that, use the command to do so after setting other SIP features using csrutil enable --without.

These commands should be good to use on Apple silicon (and Intel) Macs running Sonoma, and don’t appear to have changed in Sequoia.

Although you can check SIP status in regular user mode, making changes to it should be performed in Recovery mode, and in Apple silicon Macs any disabling of its features is likely to require Reduced Security to be set in Startup Security Utility. Status reports for most combinations of disabled features will warn that the combination being used may not be supported in the future; the only common exceptions to that are when SIP is fully enabled or fully disabled.

Thanks to Ryan for adding CSR_ALLOW_TASK_FOR_PID to the control list given above.