When Apple launched its new iPhone 17 range last week, it also announced a major change in their security. This article tries to explain what that means, and whether Apple intends building it into future Macs.

Handling of memory is an important facet of security, and securing that should eliminate plenty of vulnerabilities from Apple’s operating systems. For example, the single vulnerability fixed in Sequoia 15.6.1, and known to be actively exploited, resulted in memory corruption from processing a malicious image file. Many of those fixed in 15.6 also cite memory problems in their cause, such as corruption, out-of-bounds and use-after-free errors. Apple’s research indicates that some of the vulnerabilities used in the most sophisticated attacks, particularly those against iOS, could have been prevented by making memory handling more secure in the first place.

Over the last few years, Apple has focussed attention on making memory handling safer. Starting in iOS 15, it introduced a new interface known as kalloc_type to be used throughout the kernel and all kernel extensions. This requires Apple’s engineers to adopt its new features, and by iOS 16 it’s estimated that 95% of the kernel-space codebase in iOS had been converted. This has been fed through into macOS from Ventura onwards.

Although kalloc_type has helped, more is needed if memory handling is going to as safe as Apple wants, in what it terms Memory Integrity Enforcement. Unlike most other security measures, the principle of this is relatively simple: to allocate and control memory using secure tags. When a kernel extension, for example, requires some memory, it’s provided with a secure tag. When it wants to access any of that memory, the kext then has to provide the tag with its request. The tag is then checked and access only granted if the tag is successfully validated for the address requested.

This can be used to prevent one of the commonest types of vulnerability, accessing memory beyond that allocated in a buffer overflow. As that memory request is out-of-bounds of the memory allocated, the secure tag provided won’t extend to cover that, and the request is refused. Another common type of vulnerability is when code requests memory that has already been freed, in use-after-free access. MIE prevents that as the secure token is invalidated when that memory is freed, so the request is refused.

While the principle underlying MIE is simple, its implementation is more complex. One obvious problem is that it imposes significant overhead to memory allocation and access. The only way to work around that is to implement it in hardware, hence its current limitation to devices using Apple’s new A19 and A19 Pro chips, the first to offer that support. These come with additional features for Arm’s Enhanced Memory Tagging Extension, an option from the Armv8.7 instruction set architecture, and not yet available in an M-series chip for Macs. If you look for FEAT_MTE4 among the hardware options in sysctl (shown easily in Mints, for example), there’s no mention of it in Apple’s latest M4 chips. Additionally, for apps to support MIE, they have to opt in to enable hardware memory tagging, a feature that’s only available for now in the iPhone 17 range, including the iPhone Air.

Critics have pointed out that MIE only tackles some vulnerabilities, but Apple’s analysis of recent real-world exploits used in malware shows how the combination of defences can now disrupt the chains many rely on. By achieving that early in a chain, Apple argues that those developing attacks will be forced to redevelop the whole of that exploit chain. Neither is MIE completely new, as other operating systems like GrapheneOS, popular on Google’s Pixel devices, have already been using their own implementation of similar protection. Apple claims that those have shortcomings it has addressed in implementing MIE for iPhones.

Apple hasn’t yet made any announcement about whether or when MIE might be coming to its M-series chips using in Apple silicon Macs. I suspect we’re unlikely to see the debut of an M5 complete with Neural Accelerated GPU and hardware support for MIE in Apple’s Halloween Mac event, and more likely with macOS 26.3 early next year. Of course, MIE doesn’t protect against everything, but it should make life significantly harder for those intending to attack us.

Further reading

Apple on kalloc_type
Apple on Memory Integrity Enforcement
Arm on Enhanced Memory Tagging Extension
Apple on Enhanced Security for app developers.