In most respects, lightweight virtualisation of macOS on Apple silicon delivers almost the same performance as running code on the host. That’s the result of having direct access to CPU cores and the GPU. However, earlier implementations in Monterey and Ventura performed poorly when accessing the Data volume in the Virtual Machine, with read/write speeds measured at 4.4/0.7 and 5.4/0.7 GB/s respectively, without FileVault or other encryption. In macOS 26.3.1 both RAW and ASIF encrypted disk images show disappointing performance particularly when writing to them. This article therefore re-evaluates VM disk performance to see if that extends to VMs.

Methods

Tests were performed on two freshly made 100 GB VMs in RAW format using the macOS 26.4 IPSW, running on a Mac mini M4 Pro in macOS 26.4. VMs were given 5 CPU cores and 16 GB memory, didn’t connect to an Apple Account, and were built and run in Viable and Vimy, both of which use the standard macOS API for virtualisation.

Performance was measured using Stibium’s ‘Gold Standard’ with 5 rather than 10 test sets, reading and writing a total of 26 GB in 80 files ranging in size between 2 MB and 2 GB. Following an initial write test, the VM was restarted before performing the read test. The first VM was configured with FileVault enabled, and the second with it disabled. In addition to those, standard read/write performance was measured as before on a 100 GB RAW disk image on the host, and on a 100 GB ASIF image, both being encrypted using 256-bit AES.

Results

Measured read/write speeds were:

• Native SSD, FileVault on – 6.57/7.66 GB/s
• VM, FileVault off – 6.62/5.91 GB/s
• VM, FileVault on – 4.66/3.11 GB/s
• RAW disk image, 256-bit AES – 2.82/1.59 GB/s
• ASIF disk image, 256-bit AES – 2.85/1.76 GB/s.

With FileVault disabled, performance in the VM was surprisingly close to that of the host’s internal SSD, with a small reduction in write speed from 7.66 to 5.91 GB/s. That’s a huge improvement on previous results, with writes being almost ten times faster.

Enabling FileVault did reduce performance significantly, particularly write speed which fell to about half. However, those are still good enough to be acceptable for most purposes.

No significant change was seen in host disk image performance from those measured in 26.3.1, though, which remains substantially slower than the VM with FileVault enabled.

Conclusions

VMs are vulnerable if they don’t have FileVault enabled. Without encryption, sensitive contents would be relatively easy to access if the VM were to fall into the hands of an attacker. Enabling FileVault is thus potentially more important for a VM.

Thankfully, with such great improvements in VM disk performance, those hosted on an Apple silicon Mac’s internal SSD are unlikely to be slowed much by their disk performance.

This makes it the more puzzling that encrypted RAW and ASIF disk images should perform so poorly, and it’s disappointing to see that continues in macOS 26.4. Over the same period that VM disk performance has increased so impressively, that of disk images has headed in the opposite direction.

VMs and BSIs

If you tried installing the recent Background Security Improvement (BSI) in a macOS 26.3.1 VM, you were probably disappointed. In this respect, the VM didn’t work as expected. I was unable to find the BSI in its section in Privacy & Security settings. What did help was downloading it using SilentKnight, although that can’t install BSIs successfully. Instead, I restarted the VM and Privacy & Security offered to install the BSI at last.

Once installed, Privacy & Security offered to remove the BSI, but failed to do so, with SecurityImprovementsExtension reporting:
Rollback failed: Error Domain=SUOSUErrorDomain Code=103 "Unable to remove Background Security Improvement" UserInfo={NSLocalizedDescription=Unable to remove Background Security Improvement, NSLocalizedRecoverySuggestion=Use Software Update to install the latest version of macOS.}

For the time being BSIs appear dysfunctional in VMs.

It’s not that long ago that our Macs came with internal storage that could readily be replaced when it failed. Memories of big hard disks that died almost as soon as their warranty ran out, and of keeping a bootable clone ready in a Mac Pro, aren’t easily forgotten. So isn’t it high risk to buy a modern Mac that won’t even boot if its internal SSD has failed? Are you left wondering whether that SSD will last five years, or even three?

SSDs aren’t like hard disks

Hard disks are amazingly engineered electro-mechanical devices that spin platters at high speeds incredibly close to read-write heads. Before you even consider all the faults that can occur in their magnetic storage, there are many horrible ways they can die through mechanical disaster. Visit a data recovery shop and they’ll show you heads fused to platters, and shards of what had been storing terabytes of data before the platter shattered. And like all mechanical devices they wear out physically, no matter how carefully you care for them.

By comparison, an SSD in a Mac that has good mains power filtering, ideally a proper uninterruptible power supply (UPS), leads a sheltered life. Like other solid-state devices, so long as its power supply is clean and it doesn’t get too hot, it’s most likely to fail in the first few weeks of use, and as it’s reaching the end of its working life, in a U-shaped curve. Modern quality control has greatly reduced the number of early failures, so what we’re most concerned about is how long it will be until it wears out, as it approaches its maximum number of erase-write cycles.

Predicting wear

The theory goes that the memory cells used in SSDs can only work normally for a set number of erase-write cycles. This appears to hold good in practice, although there’s always a small number that suffer unpredictable electronic failure before they reach that. What’s more controversial is how many erase-write cycles each SSD should be capable of. Manufacturers make various claims based on accelerated ageing tests, and I suspect most come with a large dash of marketing sauce. Apple doesn’t offer figures for the SSDs it equips Macs with, but conservative estimates are around 3,000 cycles in recent models.

To work out how long you can expect your Mac’s internal SSD to last before it reaches that cycle limit, all you need do is to measure how much data is written to it, and once that is 3,000 times the capacity of the SSD, you should expect it to fail through wear. Fortunately, SSDs keep track of the amount of data written to them over their lifetime. This can be accessed through better SSD utilities like DriveDx, and I even have a feature in Mints that will do that for most internal SSDs.

Example

My iMac Pro is now well over 7 years old, as it was bought new in December 2018. It has a 1 TB internal SSD (I wanted 2 TB, but couldn’t wait for a BTO), and has run pretty well 24/7 since I got it. As I work every day, even over Christmas, and it has been my main production system, it has probably been in use for over 2,500 days now.

According to the SSD’s records, over that period its 1 TB SSD has written about 150 TB in total, from its total expected lifetime of 3,000 TB, if it reaches 3,000 erase-write cycles. At current usage rates that would take another century, or 133 years if you want to be precise. In reality, it’s generally believed that most SSDs will cease functioning after about 10 years in any case.

It’s worth noting here that, had I got the iMac Pro with my preferred 2 TB SSD, its total expected lifetime would have been 6,000 TB, and instead of lasting a total of 140 years it would in theory have gone twice that period before it wore out.

What wears out SSDs?

For an SSD to wear out when it reaches its limit of erase-write cycles, wear across its memory must be even. If that memory were to be largely full of static data, and the SSD was only able to write to 10% of its memory, then it would wear out ten times quicker than the whole SSD would. To ensure that doesn’t happen, all modern SSDs incorporate wear-levelling, which incurs its own overhead in erase-write cycles, but should ensure that the whole SSD wears out at the same rate. You can help that, and maintain faster write speeds, by keeping ample storage space free. My current target for my iMac Pro is an absolute minimum of 10% free, and 15% as much as possible.

Given that my iMac Pro has averaged about 21 TB written to its SSD each year, that works out at just under 60 GB per day. For those who are worried that the Unified log adds significantly to SSD wear, it’s not hard to estimate that’s only likely to write around 250-500 MB each day even if you leave your Mac awake and running 24/7, less than 1% of my Mac’s daily write load.

Unless you work with huge media files, by far your worst enemy is swap space used for virtual memory. When the first M1 Macs were released, base models with just 8 GB of memory and 128 GB internal SSDs were most readily available, with custom builds following later. As a result, many of those who set out to assess Apple’s new Macs ended up stress-testing those with inadequate memory and storage for the tasks they ran. Many noticed rapid changes in their SSD wear indicators, and some were getting worryingly close to the end of their expected working life after just three years.

So the best way to get a long working life from your Mac’s internal SSD is to ensure that it has sufficient memory as to never use swap space in its VM volume. Although my iMac Pro only has a 1 TB internal SSD, which is more cramped than I’d like, it has 32 GB of memory, and almost never uses swap.

Key points

• SSDs wear out differently from hard disks.
• Protect your Mac and its internal SSD with good mains power filtering, preferably using a UPS.
• Expect modern Mac internal SSDs to wear out after at least 3,000 erase-write cycles.
• To monitor wear, measure the total data written to the SSD.
• Expect an internal SSD to wear out when that total reaches 3,000 times the total capacity of the SSD.
• For a given amount of data written to an SSD, the larger the total capacity of the SSD, the slower it will wear out.
• Keep at least 10% of the SSD free at all times, with 15-25% even better.
• Ensure your Mac has sufficient memory to never use VM swap space.

One of the features introduced in the new Unified log back in macOS Sierra was its ability to protect privacy by redacting potentially sensitive contents. Although a good thing, an extraordinary mistake in High Sierra, which revealed an encryption password in plain text, has led to many entries being so heavily redacted that they’re gutted of all meaning by <private>.

Another bone of contention has been the protection provided to key information about network connections. Originally that could be removed by setting the CFNETWORK_DIAGNOSTICS environment in Terminal. Following a vulnerability addressed in Ventura 13.4 that was protected by SIP, raising the barrier for that as well.

This Friday’s magic trick is one of the most complicated I have attempted yet, and is going to show how you can put meaning back into your log and discover where all those network connections are going. Because of the changes necessary, this is easiest to perform in a macOS VM, allowing you to discard the VM when you’re done.

Setting up

You don’t have to use a VM, but if you use a Mac it shouldn’t be your production system, and you’ll need to set it back to its original settings when you’ve finished.

I took a freshly updated VM with macOS Tahoe 26.3, duplicated that in the Finder, and used the duplicate so I could easily trash it.

I then installed the profile I have made available here to remove privacy in the log. Double-click the profile, then confirm in System Settings > General > Device Management that you want to add and enable it. From then until you remove that profile, all redactions in the log should cease.

To disable SIP, I started the VM up in Recovery mode, opened Startup Security Utility and downgraded boot security there. I then opened Terminal and disabled SIP using the command
csrutil disable

If you want to, while you’re in Terminal you can run the command to enable network diagnostics
launchctl setenv CFNETWORK_DIAGNOSTICS 3
noting that, in Recovery, there’s no sudo required or available. If you do this now, it should also apply when you restart.

Once that has been completed, restart back into normal mode and check the profile is still enabled. If you didn’t enable network diagnostics there, open Terminal and enter
sudo launchctl setenv CFNETWORK_DIAGNOSTICS 3

Testing

Ensure the menu bar clock is displaying seconds, and just as it turns those to 00 seconds, run an app like SilentKnight that connects to remote sites. View the log for that period using LogUI (or whatever), and you should see the effects of both privacy removal and network diagnostics. The log is now a very different place, and far more informative.

Results

These are comparable log entries, before and after pulling this trick.

Privacy removal

Normal log entry:
00.541160 com.apple.launchservices Found application <private> to open application <private>

Privacy removed:
00.540882 com.apple.launchservices Found application SilentKnight to open application file:///Applications/SilentKnight.app/
restoring the app name and location that had been redacted to render the log entry meaningless.

Network diagnostics

Normal log entry:
01.240305 com.apple.network [C5 752CDB24-4E91-40B0-A837-9D7B9DE41B9E Hostname#7c4edf26:443 tcp, url hash: b62568a6, tls, definite, attribution: developer, context: com.apple.CFNetwork.NSURLSession.{AA60FF41-BA48-4332-B223-0C76A78CCEA7}{(null)}{Y}{2}{0x0} (private), proc: 9FC457E5-3273-37FA-BAEE-749A710F48E5, delegated upid: 0] start
which obfuscates the URL in a hash of b62568a6.

Network diagnostics:
01.103602 com.apple.network [C1 8BF615A6-CBEF-48D8-BE2F-CEF861B70BEE Hostname#99dda594:443 quic-connection, url: https://raw.githubusercontent.com/hoakleyelc/updates/master/applesilicon.plist, definite, attribution: developer, context: com.apple.CFNetwork.NSURLSession.{58709C77-3924-44EA-8563-4B44F0223AB6}{(null)}{Y}{2}{0x0} (private), proc: 06DF065F-71F6-36D9-BBAE-533B2D327BF4, delegated upid: 0] start
which reveals the full URL of https: // raw.githubusercontent.com/hoakleyelc/updates/master/applesilicon.plist, the property list on my Github containing firmware versions for Apple silicon Macs.

Remember

If you did this on a physical Mac, don’t forget to remove the profile, to enable SIP and return Startup Security Utility to Full Security, which should automatically disable network diagnostics.

In my review of apps and the validity of certificates used to sign them, I dodged the thorny issue of those apps delivered from the App Store, writing that “their signatures will remain valid as long as the developer remains a member of its Developer Program.” If you care to take a look at some of those apps using Apparency, you’ll discover that many of them have certificates that expired on 7 February 2023 at 00:00:00 GMT. This article explains why, how they should still run, but may not in the future.

As I explained, the general rule for certificates is that, once they have expired by date, they’re no longer valid. However, to ensure that third-party apps and installers can still be used after their expiry, Apple usually includes a trusted timestamp in their signature. Provided the certificate was valid at the time the app or installer was signed, then macOS should accept it as still being valid, as long as it hasn’t been revoked. But App Store apps are different again.

For reasons unknown, Apple doesn’t sign App Store apps with trusted timestamps. As a result, when its certificate expires, that app’s signature should no longer be valid, and macOS should refuse to run it on that basis. What happens in practice is that it turns a blind eye to the certificate expiry, and runs the app regardless.

What you see in the log demonstrates that. At the start of its security checks by Apple Mobile File Integrity (AMFI), securityd discovers that its certificates no longer have “temporal validity”, and fail trust evaluation:
00.701706 com.apple.securityd cert[0]: TemporalValidity =(leaf)[]> 0
00.701753 com.apple.securityd cert[1]: TemporalValidity =(leaf)[]> 0
00.703344 com.apple.securityd Trust evaluate failure: [leaf TemporalValidity] [ca1 TemporalValidity]

Those entries are repeated multiply every time that app’s trust is evaluated, including by TCC. Despite that, the app passes its Gatekeeper evaluation “due to migration”:
00.718197 com.apple.syspolicy.exec GK evaluateScanResult: 2, PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null)), 0, 0, 1, 0, 9, 0, 0
00.718213 com.apple.syspolicy.exec Allowing evaluation due to migration: PST: (path: c97bd5e74b98ed79), (team: 4GXF3JAMM4), (id: (null)), (bundle_id: (null))
00.718218 com.apple.syspolicy.exec Updating flags: [private], 513

As with all other apps, a ‘ticket check’ is performed on its CDHashes, first against the local ticket cache, then against records in the CKTicketStore via CloudKit. As App Store apps aren’t normally notarised as well, looking up their ticket in the CKTicketStore should be unsuccessful. In macOS Tahoe at least, there should be no XProtect scan or further checks, and the app should proceed to launch normally.

App Store apps are signed using an Apple Mac OS Application Signing certificate, relying on the intermediate Apple Worldwide Developer Relations Certification Authority, and back to the Apple Root CA. While the latter should expire on 9 February 2035, both the signing certificate and its intermediate have shorter lifetimes:

• Older App Store apps should have an intermediate expiry of 7 February 2023, as explained here by Apple, and more recent apps that is likely to be 10 December 2030.
• Older App Store apps are likely to have been signed with a certificate that expired on 7 February 2023, while more recent apps are likely to expire on 12 August 2026.

None of this should affect Intel Macs, although we’re likely to see increasing numbers of App Store apps that are Arm-only and won’t run on Intel systems. However, this will become more complicated with the retirement of Rosetta 2 next year.

Apple has stated its intention that full Rosetta translation support will end with macOS 27, although it intends to retain “a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles” beyond that. In practice, that means most x86 apps and command tools will stop working in macOS 28, in the autumn/fall of 2027. Apple silicon Macs will therefore continue to run Intel-only App Store apps until they are upgraded to macOS 28.

Their fallback then is to run Intel-only code in a VM running macOS 27 or earlier, as that will still be able to provide full Rosetta 2 support. Given the performance of code translated by Rosetta, and that of VMs, that’s far better than might appear. There’s one remaining problem with that, though: some App Store apps can’t run in virtualisation, as it doesn’t support connections to the App Store. Some can, and as a matter of interest the five that I used in these tests all do, although not always reliably, but others can’t. I don’t know of any reliable way of testing this other than trying it out.

Summary

• macOS security checks ignore the expiry of certificates (including intermediates) used to sign App Store apps, and allow the app to run regardless.
• Many App Store apps have expired certificates.
• This shouldn’t affect Intel Macs in the future.
• Running Intel-only App Store apps is unlikely to be supported from macOS 28 onwards, except for a limited range of unmaintained gaming titles.
• Some Intel-only App Store apps might not run in a VM with Rosetta 2 support either.

It’s not unusual for strangers to send me an email with a link to an app or document they’d like me to look at. Although always welcome, this raises the question of whether that might be yet another phishing attack. How can I tell if they’re not who they claim to be, and are just trying to lure me into downloading something malicious? This article looks at two potential solutions.

Dangerzone

Journalists face a particular problem, as they’re reliant on strangers sending them crucial information in documents. They can also be targets for more serious attacks, maybe even from state-sponsored actors. Dangerzone, originally developed by Micah Lee and now available from the Freedom of the Press Foundation, is primarily aimed at addressing their problem.

It converts a wide range of document formats to PDF, images each from PDF to pages of pixels, which it then reassembles into a fresh PDF and performs optical character recognition (OCR) to add text content to that, making the ‘safe’ PDF searchable. Stages up to the generation of images are performed inside a sandbox within a container running in a Linux virtual machine, effectively isolating the suspicious document from the host Mac.

Because the app brings its own Linux VM with LibreOffice and several Python tools, it’s large, at 2.2 GB. Its format coverage is cross-platform rather than Mac-oriented, and currently doesn’t appear to include either RTF or RTFD, although they should be low-risk. It does, though, work with all recent Microsoft Office and ODF document types.

Although still relatively early in its development, Dangerzone already does what it claims. In my brief testing, the quality of its output PDFs was high, although its OCR didn’t cope well with grey text. It also didn’t like the very long single-page PDFs exported by Safari. If what it does meets your needs, then you should test it out.

Locked-down virtual machine

If your requirements are broader than those addressed by Dangerzone, particularly if they extend to suspicious apps, you may find a solution in running a macOS virtual machine on an Apple silicon Mac. This is supported in a special locked-down version of my free virtualiser Viable, named ViableS, but you may be able to achieve something similar using a different virtualiser. I’ll explain how I do this myself.

Start with a ready-built VM of your preferred macOS version, and duplicate it to preserve the original. Because this is performed using APFS cloning, even a 100 GB VM duplicates instantly and takes little real additional space. Open this VM using Vimy or Viable and add a new standard user with a bogus name like John Smith and an obvious password like password. Populate its Applications folder with the apps you’re going to need to assess the suspicious documents or apps. In the case of PDF documents, that could include Podofyllin as the reader, and maybe Textovert for onward conversion. Switch to the standard user and copy across any suspicious files you already have, then shut the VM down.

From here on, you only run that VM using ViableS, as that runs in a sandbox and has no support for sharing folders with the host. If you need to download any suspicious apps or documents, first run ViableS with networking enabled, obtain what you need, then shut the VM down, start it up with networking disabled, and log in to that standard user account.

Your VM is now as well protected and isolated from the host Mac as possible. The virtualiser is running in a sandbox, it has no shared access to files between host and VM, it has no network connection, and is running as a standard rather than admin user, with a bogus name and password. You can now extract text and other content from suspicious documents, and save them in formats such as rich and plain text that aren’t able to be subverted by an attacker. If you’re assessing a suspicious app, you can run it here and monitor its actions and behaviour. To remind you that VM is locked down, ViableS adds a red goblin emoji to the window’s title bar.

Once you’re satisfied that the documents or apps aren’t malicious, shut the VM down, then reopen it in ViableS with a network connection to enable you to transfer any cleaned formats or other information you have recovered. When you’re done, shut it down and trash the whole VM.

Recommendation

If you receive files or links from a stranger whose identity you can’t verify with certainty, either use Dangerzone (compatible document formats only) or a locked-down VM to protect your Mac from the threat that those may be malicious. Although these might appear demanding, even over-cautious, running malware on your Mac would be a far worse outcome.

I’m very grateful to Adam Engst of TidBITS for telling me of Dangerzone.