Memory Integrity Enforcement
124 comments
·September 9, 2025tptacek
leoc
In terms of Apple Kremlinology, should this be seen a step towards full capability-based memory safety like CHERI ( https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... ) or more as Apple signaling that it thinks it can get by without something like CHERI?
bri3d
IMO it's the latter; CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture. On the other hand, heap-cookies / tag secrets can be delegated to the allocator at runtime in something like MIE / MTE, and existing component-level building blocks like the SPTM can provide some of the guarantees without needing a whole parallel memory architecture for capabilities like CHERI demands.
pizlonator
MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag)
They also imply a very different system architecture.
leoc
Sure, I'm not suggesting that Apple might actually do both at the same time. They could however implement the less burdensome one now while intending to replace it with the the all-singing-all-dancing alternative down the line.
quotemstr
> MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag)
Why would you need MTE if you have CHERI?
commandersaki
RIP Vigilant Labs
Okay a bit drastic, I don’t really know if this will affect them.
tptacek
I think they're going to print money hats, but we'll see. Remember: there isn't a realistic ceiling on what NATO-friendly intelligence and law enforcement agencies will pay for this technology; it competes with human intelligence, which is nosebleed expensive.
saurik
> We believe memory safety protections need to be strictly synchronous, on by default, and working continuously.
FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off--as this is NOT how their early kernel memory protections worked ;P. In 2015, with iOS 9, Apple released Kernel Patch Protection (KPP), which would verify that the kernel hadn't been modified asynchronously--and not even all that often, as I presume it was an expensive check--and panic if it detected corruption.
https://raw.githubusercontent.com/jakeajames/rootlessJB/mast...
> First let’s consider our worst enemy since iOS 9: KPP (Kernel Patch Protection). KPP keeps checking the kernel for changes every few minutes, when device isn’t busy.
> That “check every now and then” thing doesn’t sound too good for a security measure, and in fact a full bypass was released by Luca Todesco and it involves a design flaw. KPP does not prevent kernel patching; it just keeps checking for it and if one is caught, panics the kernel. However, since we can still patch, that opens up an opportunity for race conditions. If we do things fast enough and then revert, KPP won’t know anything ;)
MBCook
> FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off
I interpreted that as what they came up with when first looking at/starting to implement MTE, not their plan since $longTimeAgo.
Apple has certainly gotten better about security, and I suspect things like what you listed are a big part of why. They were clearly forced to learn a lot by jailbreakers.
commandersaki
Yeah it’s hard to get these things right the first time.
randyrand
> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way..
Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at the push of a button with basic modification. They just have chosen not to at this time. I feel like this paragraph is drawing a bigger distinction than actually exists.
strcat
Neither Apple or Google truly knows how widespread attacks on their products have been despite portraying it as if they have perfect insight into it. They're claiming to know something they cannot. GrapheneOS has published leaked data from exploit developers showing they're much more successful at exploiting devices and keeping up with updates than most people believe. We have access to more than what we've published, since we don't publish it without multiple independent sources to avoid leaks being identified. These tools are widely available, and it cannot be generally known when they're used whether it's data extraction or remote exploitation. Catching exploits in the wild is the exception to the rule, otherwise exploit development companies would have a much harder job needing to keep making new exploits after they're heavily used. They wouldn't value a single exploit chain nearly as much as they do if it stopped working after it was used 50k times. Law enforcement around the world has access to tools like Cellebrite Premium which are used against many people crossing borders, at protests, etc. That is usage at scale. There's far less insight into remote exploits which don't have to be distributed broadly to be broadly used.
bigiain
> tools like Cellebrite Premium which are used against many people crossing borders
I wonder when the first person will be turned away from a US border for having an iPhone Air that the CBPs phone extraction tool doesn't work on?
saagarjha
Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons.
strcat
> Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons.
If that's the case, then many of their public statements about this are extraordinarily dishonest. There are widespread exploits targeting Safari, Chrome, iOS and Android. These are not only rare attacks targeting people heavily sought out by governments, etc. They do not have nearly as much visibility into it as they make it seem.
brookst
Maybe, maybe not. But it seems fair to point out. Certainly if it was as exposed as, say, Windows, then there would have been many.
randyrand
I mean, if you read the exploit chains, they apply to all iPhones and are wormable.
saagarjha
It's mainly there as a swipe at Android. I don't think it really relates to the rest of the article (and, with no insight but with my conspiracy theory hat on, was included to peddle the merits of their App Store model).
MBCook
Even without going conspiracy theory it fits very well as a simple marketing message. “We try hard at security and we do a good job of it. Here’s our newest tool.”
Personally I didn’t read it as a swipe against Android. If it was I don’t personally know what attack(s) it’s referring to outside of the possibility of malware installed by the vendor.
But if it’s installed by the vendor, they can really do anything can’t they. That’s not really a security breach. Just trust.
philodeon
> In 2018, we were the first in the industry to deploy Pointer Authentication Codes (PAC) in the A12 Bionic chip, to protect code flow integrity in the presence of memory corruption. The strong success of this defensive mechanism in increasing exploitation complexity left no doubt that the deep integration of software and hardware security would be key to addressing some of our greatest security challenges.
There have been multiple full-chain attacks since the introduction of PAC. It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses. This should give you pause as to how secure EMTE actually is.
frosting1337
Haha, just because there's been bypasses doesn't mean it hasn't been effective.
saagarjha
> It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses.
Correction: it forces attackers to find PAC bypasses. They are not infinite.
strcat
Hijacking control flow like this is not a hard requirement of exploitation. Vulnerabilities in a specific software release are not infinite in general so that doesn't mean much.
sfink
To be fair, they didn't claim it to be a meaningful attack deterrent. They said "success...in increasing exploitation complexity".
Sure, the whole sentence is a bit of a weird mess. Paraphrased: it made exploits more complex, so we concluded that we needed a combined SW/HW approach. What I read into that is that they're admitting PAC didn't work, so they needed to come up with a new approach and part of that approach was to accept that they couldn't do it using either SW or HW alone.
Then again... I don't know much about PAC, but to me it seems like it's a HW feature that requires SW changes to make use of it, so it's kind of HW+SW already. But that's a pointless quibble; EMTE employs a lot more coordination and covers a lot more surface, iiuc.
ghostpepper
Making attackers work harder is still a worthwhile goal. No security is perfect.
bergfest
With EU chat control, the state will be on my device, having access to everything they want, decide what I can and cannot do. Once Google forces WEI on us, the whole web will get locked down. And secure boot and now MIE will make sure we can never take back our freedom.
pizlonator
This is really impressive.
It’s my understanding that this won’t protect you in the case where the attacker has a chance to try multiple times.
The approach would be something like: go out of bounds far enough to skip the directly adjacent object, or do a use after free with a lot of grooming, so that you get a a chance of getting a matching tag. The probability of getting a matching tag is 1/16.
But this post doesn’t provide enough details for me to be super confident about what I’m saying. Time will tell! If this is successful then the remaining exploit chains will have to rely on logic bugs, which would be super painful for the bad guys
tptacek
Even with Android MTE, one of the workarounds was probabilistic attacks on the small tag size, which imply multiple tries. One of the big distinctions here is uniform synchronous enforcement, so writes trap immediately and not on the next context switch.
strcat
It's typically used in synchronous or asymmetric mode on Android. The asymmetric mode preserves nearly the same performance as asymmetric while only having writes remain asynchronous. It's enforced once there's a read or system call. Synchronous is more important in the kernel due to how many holes there are for bypassing it, which is why GrapheneOS is using it as synchronous in the kernel and asymmetric in userspace. io_uring is a major example of how there could be a major bypass of asymmetric mode, although Android doesn't allow it for more than a few core processes. Deploying asynchronous is still useful since it's a widely distributed bug finding tool with near zero cost. The main cost is that it finds so many bugs which need to be addressed which is a barrier for deploying it for third party apps.
The main weakness is that MTE is only 4 bits... and it's not even 1/16 but typically 1/15 chance of bypassing it since a tag is usually reserved for metadata, free data, etc. The Linux kernel's standard implementation for in-kernel usage unnecessarily reserves more than 1 to make debugging easier. MTE clears the way for a more serious security focused memory tagging implementation with far more bits and other features. It provides a clear path to providing very strong protection against the main classes of vulnerabilities used in exploits, especially remote/proximity ones. It's a great feature but it's more what it leads to that's very impressive than the current 4 bit MTE. Getting rid of some known side channels doesn't make it into a memory safety implementation.
tptacek
You'd know better than I would; I'm a bystander on this whole area of development. I was really just responding to the notion that these countermeasures fall to attackers who get multiple bites at the apple --- those attackers are explicitly part of the threat model. I think I have realistic expectations about what this revision of MIE is going to do (raise costs, maybe over time wash out a lower tier of exploit developers on the platform).
pizlonator
Yeah that’s really good.
That makes the probability work against the attacker really well. But it’s not a guarantee
achierius
The other 15/16 attempts would crash though, and a bug that unstable is not practically usable in production, both because it would be obvious to the user / send diagnostics upstream and because when you stack a few of those 15/16s together it's actually going to take quite a while to get lucky.
strcat
Typically 14/15 since a tag is normally reserved for metadata, free data, etc. Linux kernel reserves multiple for the internal kernel usage since it was introduced upstream as more of a hardware accelerated debugging feature even though it's very useful for hardening.
pizlonator
I get that. That’s why I’m adding the caveat that this doesn’t protect you against attackers that are in a position to try multiple times
pandalicious
>The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequences to reach more than 95 percent exploitability rate — unless one of these sequences is related to the bug being exploited, following similar reasoning as our kalloc_type analysis.
Did they ever explain what that mitigation does?
sfink
Nope. I don't know why just checking the tags during speculation wouldn't stop Spectre V1, at least for cross-type accesses? I mean, it's not that simple because your program won't crash if speculation has mismatched tags. Which means you can try as many times as you want until you get lucky. But that's certainly not a "completely novel mitigation", so I'm sure I'm missing something obvious.
Perhaps the real problem is that you can use speculation to scan large amounts of memory for matching tags, some of which would be different types, so you need something to handle that?
(talking out of my butt here)
MBCook
You’re on the right track, I think. The mastodon link posted in a sibling comment within a minute of yours provides more details:
It sounds like the kernel’s allocations may only use one tag(?). So if you get in there, jackpot right? No tags to deal with.
So they’re using special compiler flags to limit all offsets to less than 4 GB. Then they placed different parts of the kernel far apart in address space with a 4 GB unmapped zone.
So if you can put your own pointer somewhere that’s exploitable in allocated kernel memory, there is no way for it to point to any other “part” of kernel memory. Only within that one “area”.
Presumably this would mean that exploiting a problem in the graphics drivers would not make it possible to provide a pointer pointing to the Secure Enclave interface code. Or something like that.
I’m not 100% on if I’m understanding it correctly.
EvanAnderson
I'm sure Apple/ARM model is vastly more sophisticated, but skimming thru made me think of the Burroughs large system memory tagging architecture: https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...
cassepipe
> Arm published the Memory Tagging Extension (MTE) specification in 2019 as a tool for hardware to help find memory corruption bugs. MTE is, at its core, a memory tagging and tag-checking system, where every memory allocation is tagged with a secret; the hardware guarantees that later requests to access memory are granted only if the request contains the correct secret. If the secrets don’t match, the app crashes, and the event is logged. This allows developers to identify memory corruption bugs immediately as they occur.
ysnp
>Google took a great first step last year when they offered MTE to those who opt in to their program for at-risk users. But even for users who turn it on, the effectiveness of MTE on Android is limited by the lack of deep integration with the operating system that distinguishes Memory Integrity Enforcement and its use of EMTE on Apple silicon.
>With the introduction of the iPhone 17 lineup and iPhone Air, we’re excited to deliver Memory Integrity Enforcement: the industry’s first ever, comprehensive, always-on memory-safety protection covering key attack surfaces — including the kernel and over 70 userland processes — built on the Enhanced Memory Tagging Extension (EMTE) and supported by secure typed allocators and tag confidentiality protections.
Of course it is a little disappointing not to see GrapheneOS's efforts in implementing [1] and raising awareness [2] recognised by others but it is very encouraging to see Apple making a serious effort on this. Hopefully it spurs Google on to do the same in Pixel OS. It should also inspire confidence that GrapheneOS are generally among the leaders in creating a system that defends the device owner against unknown threats.
[1] https://grapheneos.org/releases#2023103000 [2] https://xcancel.com/GrapheneOS/status/1716946325277909087#m
saagarjha
Apple has been working on this for years. It's not like they started thinking about memory tagging when Daniel decided to turn it on in GrapheneOS.
strcat
GrapheneOS made our own integration of MTE for hardened_malloc and has done significant work on it. It wasn't simply something we turned on. ARM designed and built the feature which was made available in Cortex cores. Google's Tensor uses standard Cortex cores so unlike Qualcomm they didn't need to make their own implementation. Google integrated it into Android and did some work to make it available on Pixels along with fixing many bugs it uncovered, although definitely not all of them. We had to fix many of the issues. Apple had to make their own hardware implementation because they have their own cores, which Qualcomm finally got done too.
Pixels are not the only Android devices with MTE anymore and haven't been for a while. We've tried it on a Samsung tablet which we would have liked to be able to support if Samsung allowed it and did a better job with updates.
GrapheneOS is not a 1 person project and not a hobby project. I wasn't the one to implement MTE for hardened_malloc and have not done most of the work on it. The work was primarily done by Dmitry Muhomor who is the lead developer of GrapheneOS and does much more development work on the OS than I do. That has been the case for years. GrapheneOS is not my personal project.
We've done a large amount of work on it including getting bugs fixed in Linux, AOSP and many third party apps. Our users are doing very broad testing of Android apps with MTE and reporting issues to developers. There's a specific crash reporting system we integrated for it to help users provide usable information to app developers. The hard part is getting apps to deal with their memory corruption bugs and eventually Google is going to need to push for that by enabling heap MTE by default at a new target API level. Ideally stack allocation MTE would also be used but it has a much higher cost than heap MTE which Apple and Google are unlikely to want to introduce for production use.
Android apps were historically largely written in Java which means they have far fewer memory corruption bugs than desktop software and MTE is far easier to deploy than it otherwise would be. Still, there are a lot of native libraries and certain kinds of apps such as AAA games with far more native code have much bigger issues with MTE.
saagarjha
None of this is wrong but none of this really has any impact on what Apple decided to do. In fact Apple very specifically chose not to go in this direction as they describe in their blog post.
ysnp
I didn't mean to imply Apple (and Google) hadn't been spearheading multi-year efforts to ship this in collaboration with Arm, I regret a little that it came across that way. Just that it would be nice to see production use of it acknowledged even just as a passing comment.
As an outsider I am quite ignorant to what security developments these companies are considering and when the trade-offs are perhaps too compromising for them to make it to production. So I can't appreciate the scale of what Apple had to do to reach this stage, whereas with GrapheneOS I know they favour privacy/security on balance. I use that as a weak signal to gauge how committed Apple/Google/Microsoft are to realising those kinds of goals too.
MBCook
Personally I had no idea anyone had shipped this. I knew that MTE existed, though I don’t think I knew about EMTE.
Nice to hear it’s already in use in some forms.
And of course it seems pretty obvious that if this is in the new iPhones it’s going to be in the M5 or M6 chips.
strcat
ARM largely built and shipped it on their own. Cortex cores were the first real world implementation. Pushing ARM to care about it as a security feature instead of only a bug finding feature is something Apple and Google are probably responsible for doing. Pixels are not the only Android devices making MTE but were the first to take advantage of the CPU support by actually setting it up and making it available for use. There are other Android devices doing that now too.
Qualcomm has to make their own implementation which has significantly delayed widespread availability. Exynos and MediaTek have it though.
slashtab
So Apple did research and Daniel just “turned it on”?! I am not talking about Hardware part even then you're biased and dismissive of other's effort.
eptcyka
This is by far the best selling point of the new series of devices.
mrpippy
Full title is "Memory Integrity Enforcement: A complete vision for memory safety in Apple devices"
Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs.
This is great, and a bit of a buried lede. Some of the economics of mercenary spyware depend on chains with interchangeable parts, and countermeasures targeting that property directly are interesting.