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.
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?
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.
> 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.
Well, Apple already routinely forces developers to recompile their applications so if Apple wants to introduce something needing a compiler / toolchain update they can do that easily. And they also control the entire SoC from start to finish and unlike pretty much everyone else also hold an ARM Architecture License so they can go and change whatever they want in the hardware side as well.
To reiterate what I've said elsewhere, CHERI does not need a whole parallel memory architecture, there is just one that gets a slight extension over a non-CHERI/MTE system to include tags. But that is the same story as MTE, which also needs to propagate the tags in the memory system (and in fact, more tags, since we just need one bit per 16 bytes, whereas MTE needs 4 bits per 16 bytes in the common scheme).
Yeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The cost to tech companies is not making it work, it's often much more boring business factors.
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.
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.
> 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 CHERI if you have working mitigations that don't demand a second bus?
I think it's two halves of the same coin and Apple chose the second half of the coin.
The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.
This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!) have an IPC channel might be affected by the timing.
There is a section in the technical reports that talks about garbage collection.
I don't think CHERI is currently being used with different privileged threads in the same address space.
I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess.
You can combine MTE and PAC, but PAC is also only probabilistic.
With CHERI, there is nothing to guess. You either have a capability or you don't.
Right, but the problem with CHERI is that you may (probabilistically) continue to have that capability even after you shouldn't. That's the problem.
That's because the capability (tagged pointer) itself is what gives you the right to access memory. So you have to find all the capabilities pointing to a segment of memory and invalidate them. Remember, capabilities are meant to be copied.
Early work on CHERI (CHERIvoke) proposed a stop-the-world barrier to revoke capabilities by doing a full scan of the program's memory (ouch!) to find and invalidate any stale capabilities. Because that is so expensive, the scan is only performed after a certain threshold amount of memory has been freed. That threshold introduces a security / battery life trade-off.
That was followed by "Cornucopia", which proposed a concurrent in-kernel scan (with some per-page flags to reduce the number of pages scanned) followed by a shorter stop-the-world. In 2024 (just last year), "Reloaded" was proposed, which add still more MMU hardware to nearly eliminate pauses, at the cost of 10% more memory traffic.
Unfortunately, the time between free and revocation introduces a short-but-not-zero window for UAF bugs/attacks. This time gap is even explicitly acknowledged in the Reloaded paper! Moreover, the Reloaded revocation algo requires blocking all threads of an application to ensure no dead capabilities are hidden in registers.
In contrast, with MTE, you just change the memory's tag on free, which immediately causes all formerly-valid pointers to the memory granule to become invalid. That's why you would want both: They're complementary.
* MTE gives truly instantaneous invalidation with zero battery impact, but only probabilistic spatial protections from attackers.
CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.
That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.
A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs.
Maybe you've been confused by a description of how it works inside a processor.
In early CHERI designs, capabilities were in different architectural processor registers from integers.
In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers.
I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.
So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?
True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag.
Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.
Where studies suggest "a lot" is sub-0.1%. For example, https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f2... was a study into porting 6 million lines of C and C++ to run a KDE+X11 desktop stack on CHERI, and saw 0.026% LoC change, or ~1.5k LoC out of ~6 million LoC, all done in just 3 months by one person. That's even an overestimate, because it includes many changes to build systems just to be able to cross-compile the projects. It's not nothing, but it's the kind of thing where a single engineer can feasibly port large bodies of code. Yes, certain systems code will be worse (like JITs), but the vast majority of cases are not that, and even those are still feasible (e.g. we have people working with Chromium and V8).
Does that study include enabling intra object overflow protection, or not?
When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection.
Finally, 6 million lines of code is not that impressive. Real OSes are measured in billions
> Does that study include enabling intra object overflow protection, or not?
>
> When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection.
Sorry, I misinterpreted what you were saying. No, that's not with subobject bounds. If you want that then yes there is more incompatibility, because C does not have a good subobject memory model. That's not really because there's anything wrong with CHERI, it's just because the language itself is at odds in places with doing that kind of enforcement with any technology. But, if you're willing to incur that additional friction (as we do for our pure-capability kernel in CheriBSD), you can enable it, and it can protect against additional vulnerabilities that other security technologies fundamentally cannot. We even provide a sliding scale of subobject bounds enforcement, where each of the three levels restricts bounds in more cases at the expense of compatibility. The architecture gives you the flexibility to decide what software model you want to enforce with it.
> Finally, 6 million lines of code is not that impressive.
We have far more than that ported, that was just one case study done in a few months by one developer. FreeBSD alone is, by my very rough estimation cloc that excludes LLVM, about 14 million lines of C and C++ (yes, I'm not distinguishing architecture-specific code and all kinds of other considerations, but it's close enough and gives an order of magnitude for the purposes of this conversation), and we have FreeBSD ported. Not to mention our work on, say, Chromium and V8 (Chromium being another set of 10s of millions of lines of code, again tractable with the engineering effort of just a few members of our research group).
> Real OSes are measured in billions
Citation needed. The Linux kernel is only a bit over 40 million lines of code these days. Real systems may well approach the billions of lines of code running once you factor in all the libraries, daemons and applications running on top of it, but that is not all low-level OS code that needs the kind of porting an OS or runtime does. Even if it were a billion lines of code, though, extrapolating at 0.026% that would be 260 kLoC changed, which isn't that scary a number.
Even V8, which is about the worse case you could possibly have (highly-stylised code written in a way that uses types in CHERI-unfriendly ways; a language runtime full of pointers; many (about 6?) different highly-optimised just-in-time compilers that embed deep knowledge of the ISAs and ABIs they are targeting and like to play games with pointers in the name of performance) we see (last I checked) ~0.8% LoC changed, or about 16k out of 2 million. The porting cost is real, but the numbers have never suggested to us it's at all intractable for industry.
> We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software
> Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem.
This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al.
There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up.
MTE helps us secure existing architectures. CHERI makes new architectures possible.
You may wish to read what the current pure-capability CHERI Linux user ABI specifies for mremap(), because we (primarily Arm, in conjunction with us) have thought about this, and the conclusion is not "the existence of mremap() makes CHERI undeployable". See https://git.morello-project.org/morello/kernel/linux/-/wikis...
Add a a sliding window aliasing mode to the hardware? You'd set a page table bit saying "check capabilities not against my VA, but those VAs over there"
That's Apple and here is Google (who have been at memory safety since the early Chrome/Android days):
Google folks were responsible for pushing on Hardware MTE ... It originally came from the folks who also did work on ASAN, syzkaller, etc ... with the help and support of folks in Android ... ARM/etc as well.
I was the director for the teams that created/pushed on it ... So I'm very familiar with the tradeoffs.
...
Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.
Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.
For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them).
This is probably not the experience you want for a user.
For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1mn of them. This is not likely to make developers happy.
Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes.
...
As an aside - It's also not obvious it's the best choice for run-time mitigation.
This is a Daniel Berlin post explaining why Google didn't originally enable MTE full-time on Android. It explicitly acknowledges that keeping MTE enforcement enabled for everyone would block vulnerabilities.
Unfortunate Daniel Berlin did not push Google to invest in MTE for security specifically, like Apple has done now with EMTE (MTE v4?). I mean, AOSP is investing heavily in rewriting core components like Binder IPC in Rust for memory safety instead... They also haven't resurrected the per-app toggle to disable JIT in ART for Java/Kotlin apps (like DVM's android:vmSafeMode)... especially after having delivered on-device "Isolated compilation" but (from what I can tell) only for OS (Java/Kotlin) components.
AOSP's security posture is frustrating (as Google seemingly solely decides what's good and what's bad and imposes that decision on each of their 3bn users & ~1m developers, despite some in the security community, like Daniel Micay, urging them to reconsider). The steps Apple has been taking (in both empowering the developers and locking down its own OS) in response to Celebgate and Pegasus hacks has been commendable.
Google did invest in MTE. In fact you linked to some of their investments that ended up trickling down to Android. The problem is actually shipping this is hard and Google was not able to do it. No, "some in the security community" being loud does not mean it is ready to ship. Google identified several problems that they were not able to solve and thus did not ship it generally.
Meanwhile Oracle has been doing it since 2015 with SPARC ADI on Solaris.
I do agree it is a pain not seeing this becoming widely adopted.
As for disabling JIT, it would have the same effect as early Androids, lagging behind Symbian devices, with applications that were wrappers around NDK code.
> As for disabling JIT, it would have the same effect as early Androids
DVM tried to mitigate the slowness with JIT+SSA, but ART mixed in JIT+SSA alongside AOT+PGO (that is, a no JITing ART means a full AOT ART, unlike in DVM where the Interp takes over when in vmSafeMode). Even if the runtime will continue to lag in terms of power/performance efficiency wrt ObjC/Swift, Google should at least let the developers decide if they want to disallow JIT from creating executable memory regions inside their app's sandbox, like Apple does: https://developer.apple.com/documentation/security/hardened-...
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.
> 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.
> 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 ;)
I have some inside knowledge here. KPP was released around the time KTRR on A11 was implemented to have some small amount of parity on <A11 SoCs. I vaguely remember the edict came down from high that such a parity should exist, and it was implemented in the best way they could within a certain time constraint. They never did that again.
> 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.
> 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.
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.
> 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.
I don't think this constitutes as widespread at least in impact, but there's been times where malicious apps have made it on the App store and used to steal cryptocurrency.
I wonder why XcodeGhost doesn't count as successful, widespread malware attack against iPhone. WeChat was infected. It was before iOS had pasteboard protections.
XcodeGhost was an attack against app developers. It did not exploit the iphone or iOS in any way, it exploited humans who build iOS apps. Memory corruption and zero-day / zero-click exploits on devices is a very different thing.
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).
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.
It's aligned with their previous statements they've made about Android. It doesn't really fit here because the mitigation described is not really protecting users from widespread malware attacks.
absolutely. it is awful lawyer twinkie talk. but the fact that we get such a detailed artile press release on MIE new aphl tech it speaks to its validity and confidence which is plainly great for all of us.
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
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.
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.
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).
I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production.
Others are aware of where MTE needs improvement and are working on it for years. Cortex shipped MTE with a side channel issue which is better than not shipping it and it will get addressed. Apple has plenty of their own side channel vulnerabilities for their CPUs. Deterministic protections provided via MTE aren't negatively impacted by the side channel and also avoid depending on only 4 bits of entropy. The obvious way to use MTE is not the only way to use it.
GrapheneOS began using MTE in production right after the Pixel 8 provided a production quality implementation, which was significantly later than it could have been made available since Pixels aren't early adopters of new Cortex cores. On those cores, asynchronous MTE is near free and asymmetric is comparable to something like -fstack-protector-strong. Synchronous is relatively expensive, so making that perform better than the early Cortex cores providing MTE seems to be where Apple made a significant improvement. Apple has higher end, larger cores than the current line of Cortex cores. Qualcomm's MTE implementation will be available soon and will be an interesting comparison. We expect Android to heavily adopt it and therefore it will be made faster out of necessity. The security advantage of synchronous over asymmetric for userspace is questionable. It's clearer within the kernel, where little CPU time is spent on an end user device. We use synchronous in the kernel and asymmetric in userspace. We haven't offered full synchronous as an option mainly because we don't have any example of it making a difference. System calls act as a synchronization point in addition to reads. io_uring isn't available beyond a few core processes, etc.
I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production.
I just want to address this part. Why shouldn't Apple advertise or market its achievements here? If they're effectively mitigating and/or frustrating real world attacks and seems to eliminate a class of security bugs, why shouldn't they boast about it; it shows that security R&D is in the forefront of the products they build which is an effective strategy for selling more product to the security conscious consumer.
Not a shill, but a shareholder, and I invest in Apple because they're at the forefront of a lot of tech.
Apple has implemented synchronous MTE with almost neutral overhead and also mitigated Spectre v1 using a novel technique that I haven't heard of before (which, alas, they don't really go into detail here); what's more, they plan to ship this to (hundreds of) millions of devices. I think these are significant improvements of the state of the art.
In theory, it is a 1/15 chance of successful attack. Which is a terribly low success rate of attack prevention.
In practice, it is 15/16 chance of detection of the exploit attempt. Which is an extraordinarily high rate of detection, which will lead to a fix by Apple.
Net net, huge win. But I agree they come across as overstating the prevention aspect.
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.
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.
It's more complicated than that, so I just use 15/16 to gesture at the general idea. E.g. some strategies for ensuring adjacent tags don't collide can include splitting the tags-range in half and tagging from one or the other based on the parity of an object within its slab allocation region. But even 1/7 is still solid.
Detection is 14/15ths of the battle. Forcing attackers to produce a brand new exploit chain every few weeks massively increases attack cost which could make it uneconomical except for national security targets.
> 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.
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.
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.
I think hackers are not ready for the idea that unhackable hardware might actually be here. Hardware that will never have an exploit found someday, never be jailbroken, never have piracy, outside of maybe nation-state attacks.
Xbox One, 2012? Never hacked.
Nintendo Switch 2, 2025? According to reverse engineers... flawlessly secure microkernel and secure monitor built over the Switch 1 generation. Meanwhile NVIDIA's boot code is formally verified this time, written in the same language (ADA SPARK) used for nuclear reactors and airplanes, on a custom RISC-V chip.
iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE.
I would deeply, strongly caution against using public exploit availability as any evidence of security. It’s a bad idea, because hundreds of market factors and random blind luck affect public exploitability more than the difficulty of developing an exploit chain.
Apple are definitely doing the best job that any firm ever has when it comes to mitigation, by a wide margin. Yet, we still see CVEs drop that are marked as used in the wild in exploit chains, so we know someone is still at it and still succeeding.
When it comes to the Xbox One, it’s an admirable job, in no small part because many of the brightest exploit developers from the Xbox 360 scene were employed to design and build the Xbox One security model. But even still, it’s still got little rips at the seams even in public: https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump...
I think the nature of the scene changed and exploits and jailbreaks are kept to small groups, individuals or are sold.
For example, I might know of an unrelated exploit I'm sitting on because I don't want it fixed and so far it hasn't been.
I think the climate has become one of those "don't correct your adversary when they make mistakes" types of things versus an older culture of release clout.
As the ability to make remote controlled hardware unhackable increases the power asymmetry between those who can create such hardware and the masses who cannot will drastically increase. I leave it as an exercise for the audience as to what the equilibrium implications are for the common man, especially in western countries where the prior equilibrium was quite different.
> ...attackers must not be able to predict tag values that the system will choose. We address this issue by frequently re-seeding the underlying pseudo-random generator used to select new tags.
This point could use more explanation. The fundamental problem here is the low entropy of the tags (only 4 bits). An attacker who randomly guesses the tags has 1/16 chance of success. That is not fixed by reseeding the PRNG. So I am not sure what they mean.
At attacher can guess, and has a 1/16 probability to guess right, but they have only one chance to guess because if you guess wrong, the process terminates (if it's a user-process) or the kernel panics (if it's in the kernel), so in the next opportunity you'll have it will be a different tag to guess.
Four bits provide too few possibilities. Since memory allocations happen millions of times per minute, the chance of collisions grows very quickly, even with periodic reseeding.
But you only get one try. 15/16 times you get a very visible failure.
It isn't great. Most users won't assume malice when an app crashes. And if they reopen it a few times your chance of succeeding goes up quickly. But this is also assuming that you need a single pointer tag to exploit something. If you need more you need to get even luckier.
So it definitely isn't perfect protection. But it isn't trivial to bypass.
This could be solved at the OS level. Just crashing and closing the app would lead the user to simply re-open it and try again. However, if iOS detects this type of crash it could sternly alert the user that the application they are using is likely compromised. It could also transmit analytics for these specific types of crashes to Apple, who would have very realtime insights into newly compromised apps. I don't think the idea here is "crash silently and let the user reopen the app as many times as they want" I think its "crash very very loudly"
> If you need more you need to get even luckier.
This is a good point. Im not an expert but im guessing one is rarely enough, which would exponentially decrease your chances of success by brute force, e.g. 2 tags would be 1/256 etc
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.
I think it is. I've seen similar rhetoric from a few people in this thread, and it's extraordinarily silly. Apple is not developing this technology to make it harder to install torrent apps*; there's real problems they're trying to solve.
*: or whatever else people use jailbreaks for these days
Yeah, this is weird logic to me. If you want control of your computing don't buy Apple hardware and hope to find an exploit. But hardware that supports running your own software without fighting you.
Maybe, but it exists now. Maybe if more people demanded this hardware then it would be more popular and not at risk of extinction. I don't know what rhetoric you are taking about? Recommending buying stuff that supports your wishes seems like pretty reasonable advice.
Maybe it is not that they want to be locked up, but they are clueless / don't care. It sucks when the reason for why we can't have nice things is... the majority of people, doesn't it? In politics they would just say democracy at work, and believe me, people are just as clueless about that as they are with technology / privacy / security.
In this very thread you can see really smart technologists largely praising this. Those aren't random Joes, and they have pretty convincing arguments - it really does improve security (and for some people, physical safety). Apple always makes very convincing points and plausible cases which are truly hard to argue against, when it takes away any kind of control from the users for their own good.
This doesn't change the fact that you're being gradually locked up, though.
Just to be clear, I don't think security improvements like this are the problem, they're genuinely welcome and appreciated. The problem is when this technology is weaponized against us by removing the escape hatches to stifle our freedoms, but that's a separate independent decision.
GrapheneOS makes similar security improvements, but it doesn't lock the escape hatches or stifle our freedoms. I could still root my device if I wanted to (although this is not recommended) and I can turn exploit protections off and customize the level of enforcement in detail, per-app, if I want/need to.
Truth be told, I do not know that much about Apple, I have no clue what their reasonings are, but you have heard of the old and tiring "think of the children" one, for example. Seemingly it seems benign and way too many fall for it, unfortunately. No one wants to seem, or even feel evil about themselves. Can you give me any references to Apple's convincing points I could read about? I wonder if it is something akin to that, or "anti-terrorism". We have to take away your freedom in the name of national security, fighting terrorism, and protecting our children, as it is the case in the political sphere.
> I don't know what rhetoric you are taking about.
The rhetoric of blaming consumers for buying the wrong product when they complain about hostile features on Apple's side of the duopoly, and then blaming them again when they switch to Android and complain about hostile features on that side.
The rhetoric of blaming the consumers for simply "not demanding" what we want with enough conviction. It's an asinine thing to suggest because freedom to install and customize has been the headline feature of Android since day 1, but they're killing it anyway because the duopoly doesn't give a shit about what we want. They know that they can make more money and they know that we don't have a choice.
> Recommending buying stuff that supports your wishes seems like pretty reasonable advice.
No, not when the market is a well-known abusive duopoly. That's either ignorant of the reality or just gaslighting.
Fair point. I think in general it is important to remember that. There are negatives to each corner of the market so a consumer can't make a perfect choice.
But in this specific case I think it does still seem strange to raise a concern that one of the most notorious locked down vendors is shipping a security improvement because it also makes it harder to get full device access.
Maybe a better way of phrasing my point is that the problem isn't that these devices are secure, that is a good feature. The problem is that Apple doesn't let you control the device. I would focus my complaints on the latter, not complain about every security improvement because it also happens to contribute to the real problem.
I wouldn't be surprised for certain kinds of secret sharing. Storage is cheap and sneaker-nets are easy. I'm sure someone is figuring out a network solution where 2 computers both have a 100tb hard drive with the same one-time pad.
"There has never been a successful, widespread malware attack against iPhone. ..."
b your iphones BEEN pwned for YEARS and it was done in minutes LOL. gtfoh
with help from ChatGPT:
Apple claims “never been a successful iPhone malware attack” Reality: WireLurker, Masque, XcodeGhost, YiSpecter, jailbreak 0-days, Pegasus/Predator/Reign 0-clicks.
>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.
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.
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.
The side channel fixes and new MTE instruction features are not specific to Apple. Apple's blog post has some significant misleading claims and omissions. It's marketing material, not a true technical post without massive bias. It's aimed at putting down the existing deployments of MTE, hyping up what they've done and even downplaying the factually widespread exploits of Apple devices which are proven to be happening. If they're not aware of how widespread the exploits of their devices are including by low level law enforcement with widely available tools, that's quite strange.
I think you have to read "widespread malware attack" in Apple lit as a term of art; it's a part of the corporate identity dating back to the inception of the iPhone and (I think maybe) ties into some policy stuff that is very salient to them right now. I think SEAR is extremely aware of what real-world exploitation of iPhones looks like. You were never going to get their unfiltered take in a public blog post like this, though.
> I think you have to read "widespread malware attack" in Apple lit as a term of art
There's widespread exploitation of Apple devices around the world by many governments, companies, etc. Apple and Google downplay it. The attacks are often not at all targeted but rather you visit a web page involving a specific political movement such as Catalan independence and get exploited via Safari or Chrome. That's not a highly targeted attack and is a typical example of how those exploits get deployed. The idea that they're solely used against specific individuals targeted by governments is simply not true. Apple and Google know that's the case but lead people to believe otherwise to promote their products as more safe than they are.
> I think SEAR is extremely aware of what real-world exploitation of iPhones looks like.
Doesn't seem that way based on their interactions with Citizen Lab and others.
I understood the point you were making previously and was not pushing back on it. I think you're wrong about SEAR's situational awareness, though. Do you know many people there? I'd be surprised if not. Platform security is kind of an incestuous scene.
We have regular contact with many people at Google in that space and nearly no contact with anyone at Apple as a whole. Sometimes people we know go to work at Apple and become nearly radio silent about anything technical.
It's often external parties finding exploits being used in the wild and reporting it to Apple and Google. Citizen Lab, Amnesty International, etc.
We regularly receive info from people working at or previously working at companies developing exploits and especially from people at organization using those exploits. A lot of our perspective on it is based on having documentation on capabilities, technical documents, etc. from this over a long period of time. Sometimes we even get access to outdated exploit code. It's major releases bringing lots of code churn, replaced components and new mitigations which seem to regularly break exploits rather than security patches. A lot of the vulnerabilities keep working for years and then suddenly the component they exploited was rewritten so it doesn't work anymore. There's not as much pressure on them to develop new exploits regularly as people seem to think.
Disclaimer: I have never worked with the team on the Apple side.
My impression is that Apple's threat intelligence effort is similar in quality to Google's. Of course external parties also help but Apple also independently finds chains sometimes.
MTE is only available in hardware on Pixel 8 and later https://googleprojectzero.blogspot.com/2023/11/first-handset.... GrapheneOS supports all the Pixel 8 and 9 series phones. They plan to support Pixel 10 once Google stop delaying their open-source releases of AOSP.
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.
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.
ARM shipped it as a standard feature of Cortex cores significantly after it was added as an ISA extension. MediaTek and Exynos provide it and Snapdragon is approaching shipping an implementation.
Google set it up for usage on Pixels, and then later Samsung and others did too. Pixel 8 was the first device where it was actually usable and production quality. GrapheneOS began using it in production nearly immediately after it launched on the Pixel 8.
Shipping MIE (or even MTE) is a many-year effort that requires several parties. I appreciate that Daniel and the GrapheneOS team have been working on making sure the allocator is MTE aware, as well as (I assume) updating Android code to work under MTE. However, to actually ship this, you need someone to design the feature itself, then threat model it, release hardware for it, plumb it through the build system and make sure the OS is aware of it, and then there's a bunch of ongoing work that needs to be done so that it can be released. Much of this work was done by Google and Arm, not Daniel, involving dozens if not hundreds of engineers.
Daniel's position on MTE for a while has been that Google is dragging their feet in turning it on, but he fails to understand that there is more to it than just flipping a switch that he does in his OS. To actually productionize it requires a huge amount of effort that Apple put in here and Daniel, as talented as he is, really can't do. We know this because Google was not able to do it even though they wanted to. (For the avoidance of doubt: Google does want to turn on MTE, they're not just dawdling "just because". The current MTE implementation is not good enough for them.)
It certainly isn't something you can just turn on. I don't know how hardened_malloc works, but one problem is that C malloc() doesn't know the type of memory it's allocating, which is naturally an issue when you need to… allocate typed memory.
You can fix this insofar as you control the compiler and calls to malloc(), which you don't, because third party code may have wrappers around it.
MTE is not about typed memory. It's for detecting invalid memory accesses outside of an object or outside of the lifetime of the object in general. hardened_malloc is the main place GrapheneOS implements MTE for userspace. In the kernel, it's implemented in various allocators and in Chromium in PartitionAlloc. The kernel and PartitionAlloc allocators have typed allocator designed unlike malloc. It's still possible to do partitioning for malloc via size classes and call locations.
Yes, this is exactly what you're missing and why what Apple has done is novel. They've combined MTE with typed allocators to reduce the performance impact and make it effective as Android failed to do.
If an attacker somehow gains out-of-bounds write capability for a tagged memory region (via a pointer that points to that region, I assume), they could potentially write into a non-tagged memory region. Since the destination region is untagged, there would be no tag check against the pointer’s tag, effectively bypassing EMTE.
> I believe they mean the source region's tag, rather than the destination.
But in the previous case, the pointer the attacker uses should already carry the source region’s tag, so it’s still unclear if this is what they meant.
I’m not sure which attack scenario they had in mind when they said this. It would help if they provided a concrete attack example.
>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.
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?
That post[^1] linked by saagarjha above is talking about the case where the typed allocator (plus the layout of kernel memory, and whatever constraints on pointer arithmetic in the kernel) makes Spectre less useful. MTE itself isn't relevant to mitigating Spectre, but putting constraints on how the addresses of certain loads in the kernel are computed makes Spectre less useful.
Remember that Spectre V1 is about causing the kernel to [incorrectly and] speculatively perform a load, and then trying to leak the loaded value by measuring the state of the cache. You might reasonably want to try this since MTE tags are stored in kernel memory.
But if the set of all possible target addresses for relevant loads on a path subject to influence by userspace can be constrained to a particular memory region, you [presumably] cannot trivially use Spectre V1 to leak values from a different region.
Also, see this[^2] paper referenced in the article.
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.
Kind of, but they don't just use one tag, they use all the tags just as userspace would. You throw all the allocations with the same type into a <4GB region and tag it, then make sure that pointer arithmetic stays within that region.
> It sounds like the kernel’s allocations may only use one tag
What about the blogpost suggested this?
" ... always-on memory safety protection for our key attack surfaces including the kernel ..."
" ... 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 ... "
Suggests to me that the kernel allocator uses a similar tagging policy as the userspace allocators do.
> 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.
Substantially less complex and therefore likely to be substantially easier to actually use.
CHERI-Morello uses 129-bit capability objects to tag operations, has a parallel capability stack, capability pointers, and requires microarchitectural support for a tag storage memory. Basically with CHERI-Morello, your memory operations also need to provide a pointer to a capability object stored in the capability store. Everything that touches memory points to your capability, which tells the processor _what_ you can do with memory and the bounds of the memory you can touch. The capability store is literally a separate bus and memory that isn't accessible by programs, so there are no secrets: even if you leak the pointer to a capability, it doesn't matter, because it's not in a place that "user code" can ever touch. This is fine in theory, but it's incredibly expensive in practice.
MIE is a much simpler notion that seems to use N-bit (maybe 4?) tags to protect heap allocations, and uses the SPTM to protect tag space from kernel compromise. If it's exactly as in the article: heap allocations get a tag. Any load/store operation to the heap needs to provide the tag that was used for their allocation in the pointer. The tag store used by the kernel allocator is protected by SPTM so you can't just dump the tags.
If you combine MIE, SPTM, and PAC, you get close-ish to CHERI, but with independent building blocks. It's less robust, but also a less granular system with less overhead.
MIE is both probabilistic (N-bits of entropy) and protected by a slightly weaker hardware protection (SPTM, which to my understanding is a bus firewall, vs. a separate bus). It also only protects heap allocations, although existing mitigations protect the stack and execution flow.
Going off of the VERY limited information in the post, my naive read is that the biggest vulnerability here will be tag collision. If you try enough times with enough heap spray, or can groom the heap repeatedly, you can probably collide a tag with however many bits of entropy are present in the system. But, because the model is synchronous, you will bus fault every time before that, unlike MTE, so you'll get caught, which is a big problem for nation-state attackers.
The early ARM Cortex MTE support has full support for synchronous and asymmetric (synchronous on reads, asynchronous on write) modes. Asynchronous was near zero cost and asymmetric comparable to a mitigation like MTE. This has been available since the launch of the Pixel 8 for Android. GrapheneOS began using it in the month the Pixel 8 launched after integrating it into hardened_maloc. It currently uses mode synchronous for the kernel and asymmetric for userspace. EMTE refers to FEAT_MTE4 which is a standard ARM extension with the 4th round of MTE features. It isn't Apple specific.
MTE is 4 bits with 16 byte granularity. There's usually at least 1 tag reserved so there are 15 random tags. It's possible to dynamically exclude tags to have extra deterministic guarantees. GrapheneOS excludes the previous random tag and adjacent random tags so there are 3 dynamically excluded tags which were themselves random.
Linux kernel MTE integration for internal usage is not very security focused and has to be replaced with a security-focused implementation integrated with pKVM at some point. Google's recently launched Advanced Protection feature currently doesn't use kernel MTE.
There is one stack, the normal program stack that's normal main memory.
> capability pointers
If you use pure-capability CHERI C/C++ then there is only one type of pointer to manage; they just are implemented as capabilities rather than integers. They're also just extensions of the existing integer registers; much as 64-bit systems extend 32-bit registers, CHERI capability registers extend the integer registers.
> requires microarchitectural support for a tag storage memory
Also true of MTE?
> your memory operations also need to provide a pointer to a capability object stored in the capability store
There is no "capability object stored in the capability store". The capability is just a thing that lives in main memory that you provide as your register operand to the memory instruction. Instead of `ldr x0, [x1]` to load from the address `x1` into `x0`, you do `ldr x0, [c1]` to load from the capability `c1`. But `c1` has all of the capability; there is no indirection. It sounds like you are thinking of classical capability systems that did have that kind of indirection, but an explicit design goal of CHERI is to not do that in order to be much more aligned with contemporary microarchitecture.
> The capability store is literally a separate bus and memory that isn't accessible by programs,
As above, there is no separate bus, and capabilities are not in separate memory. Everything lives in main memory and is accessed using the same bus. The only difference is there are now capability tags being stored alongside that data, with different schemes possible (wider SRAM, DRAM ECC bits, carving out a bit of main memory so the memory controller can store tags there and pretend to the rest of the system that memory itself stores tags). To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.
> To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.
To the architecture, there is one access mechanism with the tag bit set and one separate mechanism with the tag bit unset, no?
I thought this was the whole difference: in MTE, there is a secret tag hidden in a “normal” pointer by the allocator, and in CHERI, there is a separate architectural
route for tag=0 (normal memory) and tag=1 (capabilities memory), whether that separate route eventually goes to some partition of main memory, a separate store entirely, ECC bit stuffing, or whatever?
No. The capability itself lives in normal memory intermingling with data just like any other pointer. There is no "capabilities memory", it is just memory.
In MTE, you have the N-bit (typically 4) per-granule (typically 16 byte) "colour"/tag that is logically part of the memory but the exact storage details are abstracted by the implementation. In CHERI, you have the 1-bit capability tag that is logically part of the memory but the exact storage details are abstracted by the implementation. If you understand how MTE is able to store the colours to identify the different allocations in memory (the memory used for the allocations, not the pointers to the allocations) then you understand how CHERI stores the tags for its capabilities, because they are the same basic idea. The difference comes in how they're used: in MTE, they identify the allocation, which means you "paint" the whole allocation with the given "colour" at allocation time (malloc, new, alloca / stack variables, load time for globals), but in CHERI, they identify valid capabilities, and so only get set when you write a valid capability to that memory location (atomically and automatically). This leads to very different access patterns and densities (e.g. MTE must tag all data regardless of its type, whereas CHERI only tags pointers, meaning large chunks of plain data have large chunks of zero tag bits, so how you optimise your microarchitecture changes).
Perhaps you're getting confused with details about the "tag table + cache" implementation for how tags can be stored in commodity DRAM? For CHERI you really want 129-bit word (or some multiple thereof) memory, but commodity DRAM doesn't give you that. So as part of the memory controller (or just in front of it) you can put a "tag controller" which hides a small (< 1%) fraction of the memory and uses it to store the tags for the rest of the memory, with various caching tricks to make it go fast. But that is just the tag, and that is an implementation detail for how to pretend that your memory can tag data. You could equally have an implementation that uses wider DRAM (e.g. in the case of DRAM with ECC bits to spare). Both schemes have been implemented. But importantly memory is just 128+1-bit; the same 128 bits always store the data, whether it's some combination of integers and floats, or the raw bytes of a capability. In the former case, the 129th tag bit will be kept as 0, and in the latter case it will be kept as whatever the capability's tag is (hopefully 1).
Something I'm not clear about: is CHERI free and clear in patent terms, or do people have their hands out grasping for an MPEG-like licensing bonanza? If it's the latter then that might matter as much as purely technical obstacles to CHERI adoption.
Cambridge and Arm have made a joint statement that nothing that is essential to the deployment of CHERI ("capability essential IP") is being patented by them: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-953.pdf. As with any patent issues, you should consult your legal team and not take anyone else's word for it, because patent law is a minefield and who knows what patents may be out there lurking that nobody realises happens to cover some aspect of CHERI, or design choices in an implementation of it, as with any processor technology, but we are not out to patent it. We believe that the right thing to do is to make the technology open in order to allow it to be widely used for the good of the field.
This is the opposite of fun computing. This is commercial computing who's only use case it making sure that people can send/receive money through their computers securely. I love being able to peek/poke inside and look at my processes ram, or patch the memory of an executable. All this sounds pretty impossible on Apple's locked down systems.
They're not so much general purpose computers anymore as they are locked down bank terminals.
It's all fun and games until somebody else patches the RAM of your device, and sends your money away from your account.
More interesting is how to trace and debug code on such a CPU. Because what a debugger often does is exactly patching an executable in RAM, peeks and pokes inside, etc. If such an interface exists, I wonder how is it protected; do you need extra physical wires like JTAG? If it does not, how do you even troubleshoot a program running on the target hardware?
So what stops malware from disabling the mitigations? This is the same issue that Firefox had re: requiring all add-ons to be approved and cryptographically signed by them. If it were possible to disable it it'd be useless. So 99.999% of firefox executables simply cannot run anything not first signed by Moz.
I think if you want to tinker with hardware, you shouldn't buy Apple. It's designed for people who use it as a means to an end, and I think that's a good thing for most people (including me). I want to bank on hardware that I can trust to be secure. Nothing wrong with building your own linux box for play time though.
If you like using debuggers, don't worry, MTE gives you a lot more chances to use them since it finds a lot more crashes. It doesn't stop you writing to memory though, as long as it's the correct type.
PAC may stop you from changing values - or at least you'd have to run code in the process to change them.
It’s a shame you’re getting downvoted because I think you’re correct, and this is a perfectly valid opinion to hold.
I would respond by saying that sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.
Computing hardware in general is way less expensive and more abundant than it used to be, so there are still many options in the marketplace for people to peek and poke into.
>sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.
Yep, it's a valid use case. It's just not a general purpose computer. And it's a complete refutation of the ideals of Apple when it started out (see, 1984 commercial).
Bingo. None of this is for users. Apple somehow managed to put on a marketing mask of user respect when they’re at least as user abusive as anyone else.
In November 2021, Apple Inc. filed a complaint against NSO Group and its parent company Q Cyber Technologies in the United States District Court for the Northern District of California in relation to FORCEDENTRY, requesting injunctive relief, compensatory damages, punitive damages, and disgorgement of profits but in 2024 asked the court to dismiss the lawsuit.
The perpetrators were caught red-handed and let, go by Apple! This crime can, will, and has continued to happen due to the negligence of Apple's leadership. No doubt influenced by Tim Cook's obligation to the White House and their friends.
If I remember correctly the Israeli government stepped in and seized all the material that Apple could use in the lawsuit, so there was no point in continuing.
I hate this comic because it is profoundly lazy, and I hate it when people hand-wave away meaningful security advances with it.
Hitting people with wrenches leaves marks that can be shown to the media and truth & reconciliation commissions. Wetwork and black-bagging dissidents leaves records: training, operational, evidence after the fact. And it hardly scales – no matter what the powers at be want you to think, I think history shows there are more Hugh Thompsons than Oskar Dirlewangers, even if it takes a few years to recognize what they've done.
If we improve security enough that our adversaries are _forced_ to break out the wrenches, that's a very meaningful improvement!
Yes: if you have half of a billion dollars in BTC, sure – you're a victim to the wrench, be it private or public. If you're a terrorist mastermind, you're likely going to Gitmo and will be placed in several stress positions by mean people until you say what they want to hear.
Extreme high-value targets always have been, and always will be, vulnerable to directed attacks. But these improvements are deeply significant for everyone who is not a high-value target – like me, and (possibly) you!
In my lifetime, the government has gone from "the feds can get a warrant to record me speaking, in my own voice, to anyone I dial over my phone" to "oh, he's using (e2e encrypted platform) – that's a massive amount more work if we can even break it". That means the spectrum of people who can be targeted is significantly lower than it used to be.
Spec-fiction example: consider what the NSA could do today, with whisper.cpp & no e2e encrypted calls.
This is great, since Oracle introduced SPARC ADI, into Solaris and their Linux SPARC workloads that I keep looking forward to "C Machines" becoming a common way to fix C language issues.
Unfortunately, like in many other cases, Intel botched their MPX design, only evolutions of MTE and CHERI are around.
The problem with PowerPC AS tagging was that it relied entirely on the trap instruction. If you could control execution at all, you could skip the trap instruction and it did nothing. This implementation, by my reading, essentially adds a synchronous trap instruction after every single load and store, which builds a real security boundary (even compared to Android MTE, where reads would trap but writes were only checked at the next context switch).
Yeah, the security part wasn't baked into the hardware. It relied on the OS (it ran a virtualization layer of sorts) to enforce it via traps if it set those traps.
> As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.
The big difference with this seems like it is an actual security mechanism to block "invalid" accesses where as the tagged memory extensions only provided pointer metadata and it was up to the OS to enforce invariants.
> Extensions provide no security. [...] The tagged memory extensions don't stop you from doing anything.
SPARC ADI was a predecessor to ARM MTE. ARM MTE has been available and used in production for several years now. ADI is also 4 bit but with 64 byte granularity rather than 16 byte.
Whether you like it or not, we are in an echo chamber. We will all benefit more rapidly once we figure out how to explain to an everyday Joe Blow why this technology is necessary in their daily life to get them hyped to upgrade their cracked XR/XS/11 barely hanging onto life support.
Meanwhile, Google is doing all it can to weaken Android safety by withholding images and patches, also by failing to fully segregate applications from each other. The evidence is linked below:
Look, I’m an iOS user but this seems like flame-bait to me without any technical details. I’ve seen a lot of Google blog posts about security improvements over the years so that seems like a very sweeping assertion if you’re not going to support it.
> ... Google recently made incredibly misguided changes to Android security updates. Android security patches are (now) almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access.. Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins.
> ... The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. ...Their 3-4 month embargo has an explicit exception for binary-only releases of patches. We're fully permitted to release the December 2025 patches this month in a release but not the source code.
> Nearly all OEMs were failing to ship the monthly security patch backports despite how straightforward it is. The backports alone are not even particularly complete patches. They're only the High and Critical severity Android patches and a small subset of external patches for the Linux kernel, etc. Getting the full Android patches requires the latest stable releases.
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.
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?
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.
> 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.
Well, Apple already routinely forces developers to recompile their applications so if Apple wants to introduce something needing a compiler / toolchain update they can do that easily. And they also control the entire SoC from start to finish and unlike pretty much everyone else also hold an ARM Architecture License so they can go and change whatever they want in the hardware side as well.
To reiterate what I've said elsewhere, CHERI does not need a whole parallel memory architecture, there is just one that gets a slight extension over a non-CHERI/MTE system to include tags. But that is the same story as MTE, which also needs to propagate the tags in the memory system (and in fact, more tags, since we just need one bit per 16 bytes, whereas MTE needs 4 bits per 16 bytes in the common scheme).
> compile-and-link layer
Not to mention the dynamic linker.
Yeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The cost to tech companies is not making it work, it's often much more boring business factors.
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.
We actually have ideas for how to combine the two; see section C.5 of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.pdf
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.
Gotcha. My point about different systems architectures makes me think it’s unlikely that you’d want to do that
> 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?
Why would you need CHERI if you have working mitigations that don't demand a second bus?
I think it's two halves of the same coin and Apple chose the second half of the coin.
The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.
CHERI is deterministic.
That’s strictly better, in theory.
(Not sure it’s practically better. You could make an argument that it’s not.)
This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!) have an IPC channel might be affected by the timing.
There is a section in the technical reports that talks about garbage collection.
I don't think CHERI is currently being used with different privileged threads in the same address space.
I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess. You can combine MTE and PAC, but PAC is also only probabilistic.
With CHERI, there is nothing to guess. You either have a capability or you don't.
Right, but the problem with CHERI is that you may (probabilistically) continue to have that capability even after you shouldn't. That's the problem.
That's because the capability (tagged pointer) itself is what gives you the right to access memory. So you have to find all the capabilities pointing to a segment of memory and invalidate them. Remember, capabilities are meant to be copied.
Early work on CHERI (CHERIvoke) proposed a stop-the-world barrier to revoke capabilities by doing a full scan of the program's memory (ouch!) to find and invalidate any stale capabilities. Because that is so expensive, the scan is only performed after a certain threshold amount of memory has been freed. That threshold introduces a security / battery life trade-off.
That was followed by "Cornucopia", which proposed a concurrent in-kernel scan (with some per-page flags to reduce the number of pages scanned) followed by a shorter stop-the-world. In 2024 (just last year), "Reloaded" was proposed, which add still more MMU hardware to nearly eliminate pauses, at the cost of 10% more memory traffic.
Unfortunately, the time between free and revocation introduces a short-but-not-zero window for UAF bugs/attacks. This time gap is even explicitly acknowledged in the Reloaded paper! Moreover, the Reloaded revocation algo requires blocking all threads of an application to ensure no dead capabilities are hidden in registers.
In contrast, with MTE, you just change the memory's tag on free, which immediately causes all formerly-valid pointers to the memory granule to become invalid. That's why you would want both: They're complementary.
* MTE gives truly instantaneous invalidation with zero battery impact, but only probabilistic spatial protections from attackers.
* CHERI gives deterministic spatial protection with eventually-consistent temporal invalidation semantics.
FWIW (I am a nobody compared to you; I didn't make FIL-C :) ) - I think that MIE/MTE are practically superior to CHERI.
I also think this argument is compelling because one exists in millions of consumer drives, to-be-more (MTE -> MIE) and one does not.
Second bus?
CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.
That's not true. Capabilities are in main memory as much as any other data. The tags are in separate memory (whether a wider SRAM, DRAM ECC bits, or a separate table off on the side in a fraction of memory that's managed by the memory controller; all three schemes have been implemented and have trade-offs). But this is also true of MTE; you do not want those tags in normal software-visible main memory either, they need to be protected.
A CHERI capability is stored in main memory but with the tag bit for that location set. The tags are stored in separate memory pages, also in main memory in current designs.
Maybe you've been confused by a description of how it works inside a processor. In early CHERI designs, capabilities were in different architectural processor registers from integers.
In recent CHERI designs, the same register numbers are used for capabilities and other registers. A micro-architecture could be designed to have either all registers be capability registers with the tag bit, or use register renaming to separate integer and capability registers.
I suppose a CHERI MCU for embedded systems with small memory could theoretically have tag pages in separate SRAM instead of caching main memory, but I have not seen that.
So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?
Not saying you’d want both. Just answering why MTE isn’t a path to CHERI
But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least
True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag.
Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.
I think the intra object issue might be niche enough to not matter.
And CHERI fixes it only optionally, if you accept having to change a lot more code
Where studies suggest "a lot" is sub-0.1%. For example, https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f2... was a study into porting 6 million lines of C and C++ to run a KDE+X11 desktop stack on CHERI, and saw 0.026% LoC change, or ~1.5k LoC out of ~6 million LoC, all done in just 3 months by one person. That's even an overestimate, because it includes many changes to build systems just to be able to cross-compile the projects. It's not nothing, but it's the kind of thing where a single engineer can feasibly port large bodies of code. Yes, certain systems code will be worse (like JITs), but the vast majority of cases are not that, and even those are still feasible (e.g. we have people working with Chromium and V8).
Does that study include enabling intra object overflow protection, or not?
When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection.
Finally, 6 million lines of code is not that impressive. Real OSes are measured in billions
> Does that study include enabling intra object overflow protection, or not? > > When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection.
Sorry, I misinterpreted what you were saying. No, that's not with subobject bounds. If you want that then yes there is more incompatibility, because C does not have a good subobject memory model. That's not really because there's anything wrong with CHERI, it's just because the language itself is at odds in places with doing that kind of enforcement with any technology. But, if you're willing to incur that additional friction (as we do for our pure-capability kernel in CheriBSD), you can enable it, and it can protect against additional vulnerabilities that other security technologies fundamentally cannot. We even provide a sliding scale of subobject bounds enforcement, where each of the three levels restricts bounds in more cases at the expense of compatibility. The architecture gives you the flexibility to decide what software model you want to enforce with it.
> Finally, 6 million lines of code is not that impressive.
We have far more than that ported, that was just one case study done in a few months by one developer. FreeBSD alone is, by my very rough estimation cloc that excludes LLVM, about 14 million lines of C and C++ (yes, I'm not distinguishing architecture-specific code and all kinds of other considerations, but it's close enough and gives an order of magnitude for the purposes of this conversation), and we have FreeBSD ported. Not to mention our work on, say, Chromium and V8 (Chromium being another set of 10s of millions of lines of code, again tractable with the engineering effort of just a few members of our research group).
> Real OSes are measured in billions
Citation needed. The Linux kernel is only a bit over 40 million lines of code these days. Real systems may well approach the billions of lines of code running once you factor in all the libraries, daemons and applications running on top of it, but that is not all low-level OS code that needs the kind of porting an OS or runtime does. Even if it were a billion lines of code, though, extrapolating at 0.026% that would be 260 kLoC changed, which isn't that scary a number.
Even V8, which is about the worse case you could possibly have (highly-stylised code written in a way that uses types in CHERI-unfriendly ways; a language runtime full of pointers; many (about 6?) different highly-optimised just-in-time compilers that embed deep knowledge of the ISAs and ABIs they are targeting and like to play games with pointers in the name of performance) we see (last I checked) ~0.8% LoC changed, or about 16k out of 2 million. The porting cost is real, but the numbers have never suggested to us it's at all intractable for industry.
I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.
Yes, but CHERI opens whole new system design possibilities, including things like ultra-cheap intra-address-space security boundaries. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607...
> We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software
and https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu...
> Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem.
This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al.
There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up.
MTE helps us secure existing architectures. CHERI makes new architectures possible.
Yes, but this breaks mirror mappings.
Can you elaborate on what you perceive as broken?
mremap?
You may wish to read what the current pure-capability CHERI Linux user ABI specifies for mremap(), because we (primarily Arm, in conjunction with us) have thought about this, and the conclusion is not "the existence of mremap() makes CHERI undeployable". See https://git.morello-project.org/morello/kernel/linux/-/wikis...
Add a a sliding window aliasing mode to the hardware? You'd set a page table bit saying "check capabilities not against my VA, but those VAs over there"
Some progress on UAF though! https://dl.acm.org/doi/10.1145/3703595.3705878
> This is great ...
That's Apple and here is Google (who have been at memory safety since the early Chrome/Android days):
https://news.ycombinator.com/item?id=39671337Google Security (ex: TAG & Project Zero) do so much to tackle CSVs but with MTE the mothership dropped the ball so hard.
This is a Daniel Berlin post explaining why Google didn't originally enable MTE full-time on Android. It explicitly acknowledges that keeping MTE enforcement enabled for everyone would block vulnerabilities.
Unfortunate Daniel Berlin did not push Google to invest in MTE for security specifically, like Apple has done now with EMTE (MTE v4?). I mean, AOSP is investing heavily in rewriting core components like Binder IPC in Rust for memory safety instead... They also haven't resurrected the per-app toggle to disable JIT in ART for Java/Kotlin apps (like DVM's android:vmSafeMode)... especially after having delivered on-device "Isolated compilation" but (from what I can tell) only for OS (Java/Kotlin) components.
AOSP's security posture is frustrating (as Google seemingly solely decides what's good and what's bad and imposes that decision on each of their 3bn users & ~1m developers, despite some in the security community, like Daniel Micay, urging them to reconsider). The steps Apple has been taking (in both empowering the developers and locking down its own OS) in response to Celebgate and Pegasus hacks has been commendable.
Google did invest in MTE. In fact you linked to some of their investments that ended up trickling down to Android. The problem is actually shipping this is hard and Google was not able to do it. No, "some in the security community" being loud does not mean it is ready to ship. Google identified several problems that they were not able to solve and thus did not ship it generally.
Meanwhile Oracle has been doing it since 2015 with SPARC ADI on Solaris.
I do agree it is a pain not seeing this becoming widely adopted.
As for disabling JIT, it would have the same effect as early Androids, lagging behind Symbian devices, with applications that were wrappers around NDK code.
> As for disabling JIT, it would have the same effect as early Androids
DVM tried to mitigate the slowness with JIT+SSA, but ART mixed in JIT+SSA alongside AOT+PGO (that is, a no JITing ART means a full AOT ART, unlike in DVM where the Interp takes over when in vmSafeMode). Even if the runtime will continue to lag in terms of power/performance efficiency wrt ObjC/Swift, Google should at least let the developers decide if they want to disallow JIT from creating executable memory regions inside their app's sandbox, like Apple does: https://developer.apple.com/documentation/security/hardened-...
RIP Vigilant Labs
Okay a bit drastic, I don’t really know if this will affect them.
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.
> 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 ;)
I have some inside knowledge here. KPP was released around the time KTRR on A11 was implemented to have some small amount of parity on <A11 SoCs. I vaguely remember the edict came down from high that such a parity should exist, and it was implemented in the best way they could within a certain time constraint. They never did that again.
> 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.
Yeah it’s hard to get these things right the first time.
> 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.
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.
Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons.
> 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.
Can you be more specific on what you consider "widespread" vs "rare"?
I don't think this constitutes as widespread at least in impact, but there's been times where malicious apps have made it on the App store and used to steal cryptocurrency.
I don't really agree with your framing.
> 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?
I wonder why XcodeGhost doesn't count as successful, widespread malware attack against iPhone. WeChat was infected. It was before iOS had pasteboard protections.
[1] https://en.wikipedia.org/wiki/XcodeGhost
XcodeGhost was an attack against app developers. It did not exploit the iphone or iOS in any way, it exploited humans who build iOS apps. Memory corruption and zero-day / zero-click exploits on devices is a very different thing.
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.
I mean, if you read the exploit chains, they apply to all iPhones and are wormable.
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).
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.
It's aligned with their previous statements they've made about Android. It doesn't really fit here because the mitigation described is not really protecting users from widespread malware attacks.
absolutely. it is awful lawyer twinkie talk. but the fact that we get such a detailed artile press release on MIE new aphl tech it speaks to its validity and confidence which is plainly great for all of us.
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
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.
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.
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).
I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production.
Others are aware of where MTE needs improvement and are working on it for years. Cortex shipped MTE with a side channel issue which is better than not shipping it and it will get addressed. Apple has plenty of their own side channel vulnerabilities for their CPUs. Deterministic protections provided via MTE aren't negatively impacted by the side channel and also avoid depending on only 4 bits of entropy. The obvious way to use MTE is not the only way to use it.
GrapheneOS began using MTE in production right after the Pixel 8 provided a production quality implementation, which was significantly later than it could have been made available since Pixels aren't early adopters of new Cortex cores. On those cores, asynchronous MTE is near free and asymmetric is comparable to something like -fstack-protector-strong. Synchronous is relatively expensive, so making that perform better than the early Cortex cores providing MTE seems to be where Apple made a significant improvement. Apple has higher end, larger cores than the current line of Cortex cores. Qualcomm's MTE implementation will be available soon and will be an interesting comparison. We expect Android to heavily adopt it and therefore it will be made faster out of necessity. The security advantage of synchronous over asymmetric for userspace is questionable. It's clearer within the kernel, where little CPU time is spent on an end user device. We use synchronous in the kernel and asymmetric in userspace. We haven't offered full synchronous as an option mainly because we don't have any example of it making a difference. System calls act as a synchronization point in addition to reads. io_uring isn't available beyond a few core processes, etc.
I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production.
I just want to address this part. Why shouldn't Apple advertise or market its achievements here? If they're effectively mitigating and/or frustrating real world attacks and seems to eliminate a class of security bugs, why shouldn't they boast about it; it shows that security R&D is in the forefront of the products they build which is an effective strategy for selling more product to the security conscious consumer.
Not a shill, but a shareholder, and I invest in Apple because they're at the forefront of a lot of tech.
Apple has implemented synchronous MTE with almost neutral overhead and also mitigated Spectre v1 using a novel technique that I haven't heard of before (which, alas, they don't really go into detail here); what's more, they plan to ship this to (hundreds of) millions of devices. I think these are significant improvements of the state of the art.
> also mitigated Spectre v1 using a novel technique that I haven't heard of before
Unsure about iOS, but back then, Webkit published their initial mitigations (like: Index masking, Pointer poisoning): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
In theory, it is a 1/15 chance of successful attack. Which is a terribly low success rate of attack prevention.
In practice, it is 15/16 chance of detection of the exploit attempt. Which is an extraordinarily high rate of detection, which will lead to a fix by Apple.
Net net, huge win. But I agree they come across as overstating the prevention aspect.
1/16 is a miserable rate for commercial spyware; it would be very difficult to sell this kind of product for a remote 0- or 1-click attack.
It’s miserable today because you’d be competing with others selling deterministic attacks.
But what if the only thing available to purchase is 1/16 or 1/256? Then maybe it’s not so miserable
Yeah that’s really good.
That makes the probability work against the attacker really well. But it’s not a guarantee
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.
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.
It's more complicated than that, so I just use 15/16 to gesture at the general idea. E.g. some strategies for ensuring adjacent tags don't collide can include splitting the tags-range in half and tagging from one or the other based on the parity of an object within its slab allocation region. But even 1/7 is still solid.
93%, 94%, it's not a huge difference.
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
Detection is 14/15ths of the battle. Forcing attackers to produce a brand new exploit chain every few weeks massively increases attack cost which could make it uneconomical except for national security targets.
It will be really interesting to see how well that part of the story works out!
What we're essentially saying is that evading detection is now 14/15 of the battle, from the attacker's perspective. Those people are very clever
It also won't help with supply-chain attacks. Executed by e.g. a state actor who is playing the long game.
> 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.
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.
Making attackers work harder is still a worthwhile goal. No security is perfect.
Also, all of these security improvements are nearly-free assert()s which catch memory bugs.
> 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.
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.
Memory safety issues, or ROP gadgets, and the like are basically infinite
Haha, just because there's been bypasses doesn't mean it hasn't been effective.
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...
I think hackers are not ready for the idea that unhackable hardware might actually be here. Hardware that will never have an exploit found someday, never be jailbroken, never have piracy, outside of maybe nation-state attacks.
Xbox One, 2012? Never hacked.
Nintendo Switch 2, 2025? According to reverse engineers... flawlessly secure microkernel and secure monitor built over the Switch 1 generation. Meanwhile NVIDIA's boot code is formally verified this time, written in the same language (ADA SPARK) used for nuclear reactors and airplanes, on a custom RISC-V chip.
iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE.
I would deeply, strongly caution against using public exploit availability as any evidence of security. It’s a bad idea, because hundreds of market factors and random blind luck affect public exploitability more than the difficulty of developing an exploit chain.
Apple are definitely doing the best job that any firm ever has when it comes to mitigation, by a wide margin. Yet, we still see CVEs drop that are marked as used in the wild in exploit chains, so we know someone is still at it and still succeeding.
When it comes to the Xbox One, it’s an admirable job, in no small part because many of the brightest exploit developers from the Xbox 360 scene were employed to design and build the Xbox One security model. But even still, it’s still got little rips at the seams even in public: https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump...
I think the nature of the scene changed and exploits and jailbreaks are kept to small groups, individuals or are sold.
For example, I might know of an unrelated exploit I'm sitting on because I don't want it fixed and so far it hasn't been.
I think the climate has become one of those "don't correct your adversary when they make mistakes" types of things versus an older culture of release clout.
Saying "never" is too bold. But it's definitely getting immensely difficult.
There are still plenty of other flaws besides memory unsafety to exploit. I doubt that we'll see like a formally proven mainstream OS for a long time.
True. But if developing an exploit takes 15 years and the average life of the device is five then to some degree that is effectively perfect.
Those flaws get harder the more restricted devices are.
Depends. If "restriction" means "complexity" then you may end up with scenarios like the BlastDoor vulns (eg. FORCEDENTRY).
Israeli companies and agencies will surely find a way.. even if software/hardware might really be unhackable, it seems people will never be..
> iPhone? iOS 17 and 18 have never been jailbroken; now we introduce MIE.
So far as you know. There's a reason they call them zero-day vulnerabilities.
Unhackable and backdoored. Operation Triangulation would have been impossible without Apple backdooring their own hardware.
>Xbox One, 2012? Never hacked.
Not publicly :)
As the ability to make remote controlled hardware unhackable increases the power asymmetry between those who can create such hardware and the masses who cannot will drastically increase. I leave it as an exercise for the audience as to what the equilibrium implications are for the common man, especially in western countries where the prior equilibrium was quite different.
> ...attackers must not be able to predict tag values that the system will choose. We address this issue by frequently re-seeding the underlying pseudo-random generator used to select new tags.
This point could use more explanation. The fundamental problem here is the low entropy of the tags (only 4 bits). An attacker who randomly guesses the tags has 1/16 chance of success. That is not fixed by reseeding the PRNG. So I am not sure what they mean.
At attacher can guess, and has a 1/16 probability to guess right, but they have only one chance to guess because if you guess wrong, the process terminates (if it's a user-process) or the kernel panics (if it's in the kernel), so in the next opportunity you'll have it will be a different tag to guess.
Four bits provide too few possibilities. Since memory allocations happen millions of times per minute, the chance of collisions grows very quickly, even with periodic reseeding.
But you only get one try. 15/16 times you get a very visible failure.
It isn't great. Most users won't assume malice when an app crashes. And if they reopen it a few times your chance of succeeding goes up quickly. But this is also assuming that you need a single pointer tag to exploit something. If you need more you need to get even luckier.
So it definitely isn't perfect protection. But it isn't trivial to bypass.
This could be solved at the OS level. Just crashing and closing the app would lead the user to simply re-open it and try again. However, if iOS detects this type of crash it could sternly alert the user that the application they are using is likely compromised. It could also transmit analytics for these specific types of crashes to Apple, who would have very realtime insights into newly compromised apps. I don't think the idea here is "crash silently and let the user reopen the app as many times as they want" I think its "crash very very loudly"
> If you need more you need to get even luckier.
This is a good point. Im not an expert but im guessing one is rarely enough, which would exponentially decrease your chances of success by brute force, e.g. 2 tags would be 1/256 etc
The idea is that a tag failure crashes your process.
This is by far the best selling point of the new series of devices.
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.
> MIE will make sure we can never take back our freedom.
Is the implication here that making phones more secure is... bad? Because it makes jailbreaks harder to develop?
I think it is. I've seen similar rhetoric from a few people in this thread, and it's extraordinarily silly. Apple is not developing this technology to make it harder to install torrent apps*; there's real problems they're trying to solve.
*: or whatever else people use jailbreaks for these days
Yes, absolutely.
Just like any weapon, "security" is only good if it's in your control. When the noose is around your neck, you'd better hope it easily breaks.
That is a good way to put it, stealing it.
Yeah, this is weird logic to me. If you want control of your computing don't buy Apple hardware and hope to find an exploit. But hardware that supports running your own software without fighting you.
> Buy hardware that supports running your own software without fighting you.
It will be very hard to buy something that won't exist in the near future. This rhetoric should've died a decade ago.
Maybe, but it exists now. Maybe if more people demanded this hardware then it would be more popular and not at risk of extinction. I don't know what rhetoric you are taking about? Recommending buying stuff that supports your wishes seems like pretty reasonable advice.
Voting with your wallet doesn't work when the overwhelming majority does want to be locked up.
Maybe it is not that they want to be locked up, but they are clueless / don't care. It sucks when the reason for why we can't have nice things is... the majority of people, doesn't it? In politics they would just say democracy at work, and believe me, people are just as clueless about that as they are with technology / privacy / security.
In this very thread you can see really smart technologists largely praising this. Those aren't random Joes, and they have pretty convincing arguments - it really does improve security (and for some people, physical safety). Apple always makes very convincing points and plausible cases which are truly hard to argue against, when it takes away any kind of control from the users for their own good.
This doesn't change the fact that you're being gradually locked up, though.
Just to be clear, I don't think security improvements like this are the problem, they're genuinely welcome and appreciated. The problem is when this technology is weaponized against us by removing the escape hatches to stifle our freedoms, but that's a separate independent decision.
GrapheneOS makes similar security improvements, but it doesn't lock the escape hatches or stifle our freedoms. I could still root my device if I wanted to (although this is not recommended) and I can turn exploit protections off and customize the level of enforcement in detail, per-app, if I want/need to.
Truth be told, I do not know that much about Apple, I have no clue what their reasonings are, but you have heard of the old and tiring "think of the children" one, for example. Seemingly it seems benign and way too many fall for it, unfortunately. No one wants to seem, or even feel evil about themselves. Can you give me any references to Apple's convincing points I could read about? I wonder if it is something akin to that, or "anti-terrorism". We have to take away your freedom in the name of national security, fighting terrorism, and protecting our children, as it is the case in the political sphere.
s/smart/authoritarian/
> I don't know what rhetoric you are taking about.
The rhetoric of blaming consumers for buying the wrong product when they complain about hostile features on Apple's side of the duopoly, and then blaming them again when they switch to Android and complain about hostile features on that side.
The rhetoric of blaming the consumers for simply "not demanding" what we want with enough conviction. It's an asinine thing to suggest because freedom to install and customize has been the headline feature of Android since day 1, but they're killing it anyway because the duopoly doesn't give a shit about what we want. They know that they can make more money and they know that we don't have a choice.
> Recommending buying stuff that supports your wishes seems like pretty reasonable advice.
No, not when the market is a well-known abusive duopoly. That's either ignorant of the reality or just gaslighting.
Fair point. I think in general it is important to remember that. There are negatives to each corner of the market so a consumer can't make a perfect choice.
But in this specific case I think it does still seem strange to raise a concern that one of the most notorious locked down vendors is shipping a security improvement because it also makes it harder to get full device access.
Maybe a better way of phrasing my point is that the problem isn't that these devices are secure, that is a good feature. The problem is that Apple doesn't let you control the device. I would focus my complaints on the latter, not complain about every security improvement because it also happens to contribute to the real problem.
That is, unless we balkanize our systems and services.
> That is, unless we balkanize our systems and services.
...all the way back to pen and paper
I wouldn't be surprised for certain kinds of secret sharing. Storage is cheap and sneaker-nets are easy. I'm sure someone is figuring out a network solution where 2 computers both have a 100tb hard drive with the same one-time pad.
https://en.wikipedia.org/wiki/One-time_pad
What is WEI?
Google proposed it as DRM for web pages in 2023. After much outcry it was unceremoniously withdrawn.
"There has never been a successful, widespread malware attack against iPhone. ..."
b your iphones BEEN pwned for YEARS and it was done in minutes LOL. gtfoh
with help from ChatGPT: Apple claims “never been a successful iPhone malware attack” Reality: WireLurker, Masque, XcodeGhost, YiSpecter, jailbreak 0-days, Pegasus/Predator/Reign 0-clicks.
iPhones pwned for yrs — by kids in pajamas
Yes, but with MIE there will come an end to that, hopefully.
The business model of Pegasus et al. will be gone.
row/throw hammer or a bit flip
>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
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.
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.
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.
The side channel fixes and new MTE instruction features are not specific to Apple. Apple's blog post has some significant misleading claims and omissions. It's marketing material, not a true technical post without massive bias. It's aimed at putting down the existing deployments of MTE, hyping up what they've done and even downplaying the factually widespread exploits of Apple devices which are proven to be happening. If they're not aware of how widespread the exploits of their devices are including by low level law enforcement with widely available tools, that's quite strange.
I think you have to read "widespread malware attack" in Apple lit as a term of art; it's a part of the corporate identity dating back to the inception of the iPhone and (I think maybe) ties into some policy stuff that is very salient to them right now. I think SEAR is extremely aware of what real-world exploitation of iPhones looks like. You were never going to get their unfiltered take in a public blog post like this, though.
> I think you have to read "widespread malware attack" in Apple lit as a term of art
There's widespread exploitation of Apple devices around the world by many governments, companies, etc. Apple and Google downplay it. The attacks are often not at all targeted but rather you visit a web page involving a specific political movement such as Catalan independence and get exploited via Safari or Chrome. That's not a highly targeted attack and is a typical example of how those exploits get deployed. The idea that they're solely used against specific individuals targeted by governments is simply not true. Apple and Google know that's the case but lead people to believe otherwise to promote their products as more safe than they are.
> I think SEAR is extremely aware of what real-world exploitation of iPhones looks like.
Doesn't seem that way based on their interactions with Citizen Lab and others.
I understood the point you were making previously and was not pushing back on it. I think you're wrong about SEAR's situational awareness, though. Do you know many people there? I'd be surprised if not. Platform security is kind of an incestuous scene.
We have regular contact with many people at Google in that space and nearly no contact with anyone at Apple as a whole. Sometimes people we know go to work at Apple and become nearly radio silent about anything technical.
It's often external parties finding exploits being used in the wild and reporting it to Apple and Google. Citizen Lab, Amnesty International, etc.
We regularly receive info from people working at or previously working at companies developing exploits and especially from people at organization using those exploits. A lot of our perspective on it is based on having documentation on capabilities, technical documents, etc. from this over a long period of time. Sometimes we even get access to outdated exploit code. It's major releases bringing lots of code churn, replaced components and new mitigations which seem to regularly break exploits rather than security patches. A lot of the vulnerabilities keep working for years and then suddenly the component they exploited was rewritten so it doesn't work anymore. There's not as much pressure on them to develop new exploits regularly as people seem to think.
Disclaimer: I have never worked with the team on the Apple side.
My impression is that Apple's threat intelligence effort is similar in quality to Google's. Of course external parties also help but Apple also independently finds chains sometimes.
The choices they made are novel to my understanding.
Is MTE on GrapheneOS restricted to some (newest?) Pixel models? Or does it work with all models that are currently supported by GrapheneOS itself?
MTE is only available in hardware on Pixel 8 and later https://googleprojectzero.blogspot.com/2023/11/first-handset.... GrapheneOS supports all the Pixel 8 and 9 series phones. They plan to support Pixel 10 once Google stop delaying their open-source releases of AOSP.
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.
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.
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.
ARM shipped it as a standard feature of Cortex cores significantly after it was added as an ISA extension. MediaTek and Exynos provide it and Snapdragon is approaching shipping an implementation.
Google set it up for usage on Pixels, and then later Samsung and others did too. Pixel 8 was the first device where it was actually usable and production quality. GrapheneOS began using it in production nearly immediately after it launched on the Pixel 8.
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.
Shipping MIE (or even MTE) is a many-year effort that requires several parties. I appreciate that Daniel and the GrapheneOS team have been working on making sure the allocator is MTE aware, as well as (I assume) updating Android code to work under MTE. However, to actually ship this, you need someone to design the feature itself, then threat model it, release hardware for it, plumb it through the build system and make sure the OS is aware of it, and then there's a bunch of ongoing work that needs to be done so that it can be released. Much of this work was done by Google and Arm, not Daniel, involving dozens if not hundreds of engineers.
Daniel's position on MTE for a while has been that Google is dragging their feet in turning it on, but he fails to understand that there is more to it than just flipping a switch that he does in his OS. To actually productionize it requires a huge amount of effort that Apple put in here and Daniel, as talented as he is, really can't do. We know this because Google was not able to do it even though they wanted to. (For the avoidance of doubt: Google does want to turn on MTE, they're not just dawdling "just because". The current MTE implementation is not good enough for them.)
It certainly isn't something you can just turn on. I don't know how hardened_malloc works, but one problem is that C malloc() doesn't know the type of memory it's allocating, which is naturally an issue when you need to… allocate typed memory.
You can fix this insofar as you control the compiler and calls to malloc(), which you don't, because third party code may have wrappers around it.
MTE is not about typed memory. It's for detecting invalid memory accesses outside of an object or outside of the lifetime of the object in general. hardened_malloc is the main place GrapheneOS implements MTE for userspace. In the kernel, it's implemented in various allocators and in Chromium in PartitionAlloc. The kernel and PartitionAlloc allocators have typed allocator designed unlike malloc. It's still possible to do partitioning for malloc via size classes and call locations.
Yes, this is exactly what you're missing and why what Apple has done is novel. They've combined MTE with typed allocators to reduce the performance impact and make it effective as Android failed to do.
> ... With Enhanced MTE, we instead specify that accessing non-tagged memory from a tagged memory region requires knowing that region’s tag, ...
I got a bit confused when reading this. What does it mean to "know the tag" if the memory region is untagged?
I believe they mean the source region's tag, rather than the destination.
Not sure if I understand this correctly:
If an attacker somehow gains out-of-bounds write capability for a tagged memory region (via a pointer that points to that region, I assume), they could potentially write into a non-tagged memory region. Since the destination region is untagged, there would be no tag check against the pointer’s tag, effectively bypassing EMTE.
> I believe they mean the source region's tag, rather than the destination.
But in the previous case, the pointer the attacker uses should already carry the source region’s tag, so it’s still unclear if this is what they meant.
I’m not sure which attack scenario they had in mind when they said this. It would help if they provided a concrete attack example.
Full title is "Memory Integrity Enforcement: A complete vision for memory safety in Apple devices"
>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?
https://mastodon.online/@ezhes_/115175838087995856
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)
That post[^1] linked by saagarjha above is talking about the case where the typed allocator (plus the layout of kernel memory, and whatever constraints on pointer arithmetic in the kernel) makes Spectre less useful. MTE itself isn't relevant to mitigating Spectre, but putting constraints on how the addresses of certain loads in the kernel are computed makes Spectre less useful.
Remember that Spectre V1 is about causing the kernel to [incorrectly and] speculatively perform a load, and then trying to leak the loaded value by measuring the state of the cache. You might reasonably want to try this since MTE tags are stored in kernel memory.
But if the set of all possible target addresses for relevant loads on a path subject to influence by userspace can be constrained to a particular memory region, you [presumably] cannot trivially use Spectre V1 to leak values from a different region.
Also, see this[^2] paper referenced in the article.
[^1]: https://mastodon.online/@ezhes_/115175838087995856
[^2]: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=983...
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.
Kind of, but they don't just use one tag, they use all the tags just as userspace would. You throw all the allocations with the same type into a <4GB region and tag it, then make sure that pointer arithmetic stays within that region.
> It sounds like the kernel’s allocations may only use one tag
What about the blogpost suggested this?
" ... always-on memory safety protection for our key attack surfaces including the kernel ..."
" ... 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 ... "
Suggests to me that the kernel allocator uses a similar tagging policy as the userspace allocators do.
> 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.
Is this only available on iPhone 17 for now?
Available on all the models announced today: air and 17/17 pro (a19 chip and above)
Presumably future M5 model Macs and iPads.
I hope so too, but I could see it being in the M6 instead.
The 202X M-series don’t always have the same core revisions as the A-series. Sometimes they’re based on the cores from 202X-1.
Given how nice a feature it is I certainly hope it’s in the M5.
How does this compare to CHERI?
Substantially less complex and therefore likely to be substantially easier to actually use.
CHERI-Morello uses 129-bit capability objects to tag operations, has a parallel capability stack, capability pointers, and requires microarchitectural support for a tag storage memory. Basically with CHERI-Morello, your memory operations also need to provide a pointer to a capability object stored in the capability store. Everything that touches memory points to your capability, which tells the processor _what_ you can do with memory and the bounds of the memory you can touch. The capability store is literally a separate bus and memory that isn't accessible by programs, so there are no secrets: even if you leak the pointer to a capability, it doesn't matter, because it's not in a place that "user code" can ever touch. This is fine in theory, but it's incredibly expensive in practice.
MIE is a much simpler notion that seems to use N-bit (maybe 4?) tags to protect heap allocations, and uses the SPTM to protect tag space from kernel compromise. If it's exactly as in the article: heap allocations get a tag. Any load/store operation to the heap needs to provide the tag that was used for their allocation in the pointer. The tag store used by the kernel allocator is protected by SPTM so you can't just dump the tags.
If you combine MIE, SPTM, and PAC, you get close-ish to CHERI, but with independent building blocks. It's less robust, but also a less granular system with less overhead.
MIE is both probabilistic (N-bits of entropy) and protected by a slightly weaker hardware protection (SPTM, which to my understanding is a bus firewall, vs. a separate bus). It also only protects heap allocations, although existing mitigations protect the stack and execution flow.
Going off of the VERY limited information in the post, my naive read is that the biggest vulnerability here will be tag collision. If you try enough times with enough heap spray, or can groom the heap repeatedly, you can probably collide a tag with however many bits of entropy are present in the system. But, because the model is synchronous, you will bus fault every time before that, unlike MTE, so you'll get caught, which is a big problem for nation-state attackers.
The early ARM Cortex MTE support has full support for synchronous and asymmetric (synchronous on reads, asynchronous on write) modes. Asynchronous was near zero cost and asymmetric comparable to a mitigation like MTE. This has been available since the launch of the Pixel 8 for Android. GrapheneOS began using it in the month the Pixel 8 launched after integrating it into hardened_maloc. It currently uses mode synchronous for the kernel and asymmetric for userspace. EMTE refers to FEAT_MTE4 which is a standard ARM extension with the 4th round of MTE features. It isn't Apple specific.
MTE is 4 bits with 16 byte granularity. There's usually at least 1 tag reserved so there are 15 random tags. It's possible to dynamically exclude tags to have extra deterministic guarantees. GrapheneOS excludes the previous random tag and adjacent random tags so there are 3 dynamically excluded tags which were themselves random.
Linux kernel MTE integration for internal usage is not very security focused and has to be replaced with a security-focused implementation integrated with pKVM at some point. Google's recently launched Advanced Protection feature currently doesn't use kernel MTE.
> has a parallel capability stack
There is one stack, the normal program stack that's normal main memory.
> capability pointers
If you use pure-capability CHERI C/C++ then there is only one type of pointer to manage; they just are implemented as capabilities rather than integers. They're also just extensions of the existing integer registers; much as 64-bit systems extend 32-bit registers, CHERI capability registers extend the integer registers.
> requires microarchitectural support for a tag storage memory
Also true of MTE?
> your memory operations also need to provide a pointer to a capability object stored in the capability store
There is no "capability object stored in the capability store". The capability is just a thing that lives in main memory that you provide as your register operand to the memory instruction. Instead of `ldr x0, [x1]` to load from the address `x1` into `x0`, you do `ldr x0, [c1]` to load from the capability `c1`. But `c1` has all of the capability; there is no indirection. It sounds like you are thinking of classical capability systems that did have that kind of indirection, but an explicit design goal of CHERI is to not do that in order to be much more aligned with contemporary microarchitecture.
> The capability store is literally a separate bus and memory that isn't accessible by programs,
As above, there is no separate bus, and capabilities are not in separate memory. Everything lives in main memory and is accessed using the same bus. The only difference is there are now capability tags being stored alongside that data, with different schemes possible (wider SRAM, DRAM ECC bits, carving out a bit of main memory so the memory controller can store tags there and pretend to the rest of the system that memory itself stores tags). To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.
> To anything interacting with the memory subsystem, there is one bus, and the tags flow with the data on it.
To the architecture, there is one access mechanism with the tag bit set and one separate mechanism with the tag bit unset, no?
I thought this was the whole difference: in MTE, there is a secret tag hidden in a “normal” pointer by the allocator, and in CHERI, there is a separate architectural route for tag=0 (normal memory) and tag=1 (capabilities memory), whether that separate route eventually goes to some partition of main memory, a separate store entirely, ECC bit stuffing, or whatever?
No. The capability itself lives in normal memory intermingling with data just like any other pointer. There is no "capabilities memory", it is just memory.
In MTE, you have the N-bit (typically 4) per-granule (typically 16 byte) "colour"/tag that is logically part of the memory but the exact storage details are abstracted by the implementation. In CHERI, you have the 1-bit capability tag that is logically part of the memory but the exact storage details are abstracted by the implementation. If you understand how MTE is able to store the colours to identify the different allocations in memory (the memory used for the allocations, not the pointers to the allocations) then you understand how CHERI stores the tags for its capabilities, because they are the same basic idea. The difference comes in how they're used: in MTE, they identify the allocation, which means you "paint" the whole allocation with the given "colour" at allocation time (malloc, new, alloca / stack variables, load time for globals), but in CHERI, they identify valid capabilities, and so only get set when you write a valid capability to that memory location (atomically and automatically). This leads to very different access patterns and densities (e.g. MTE must tag all data regardless of its type, whereas CHERI only tags pointers, meaning large chunks of plain data have large chunks of zero tag bits, so how you optimise your microarchitecture changes).
Perhaps you're getting confused with details about the "tag table + cache" implementation for how tags can be stored in commodity DRAM? For CHERI you really want 129-bit word (or some multiple thereof) memory, but commodity DRAM doesn't give you that. So as part of the memory controller (or just in front of it) you can put a "tag controller" which hides a small (< 1%) fraction of the memory and uses it to store the tags for the rest of the memory, with various caching tricks to make it go fast. But that is just the tag, and that is an implementation detail for how to pretend that your memory can tag data. You could equally have an implementation that uses wider DRAM (e.g. in the case of DRAM with ECC bits to spare). Both schemes have been implemented. But importantly memory is just 128+1-bit; the same 128 bits always store the data, whether it's some combination of integers and floats, or the raw bytes of a capability. In the former case, the 129th tag bit will be kept as 0, and in the latter case it will be kept as whatever the capability's tag is (hopefully 1).
Something I'm not clear about: is CHERI free and clear in patent terms, or do people have their hands out grasping for an MPEG-like licensing bonanza? If it's the latter then that might matter as much as purely technical obstacles to CHERI adoption.
Cambridge and Arm have made a joint statement that nothing that is essential to the deployment of CHERI ("capability essential IP") is being patented by them: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-953.pdf. As with any patent issues, you should consult your legal team and not take anyone else's word for it, because patent law is a minefield and who knows what patents may be out there lurking that nobody realises happens to cover some aspect of CHERI, or design choices in an implementation of it, as with any processor technology, but we are not out to patent it. We believe that the right thing to do is to make the technology open in order to allow it to be widely used for the good of the field.
SPTM isn't a hardware feature, it's basically a hypervisor that manages the page tables and tag memory so that the kernel doesn't own its own tags.
https://saaramar.github.io/memory_safety_blogpost_2022/ is a nice article which goes into this topic for MTE in the past.
And of note, the Apple implementation basically forces the invariants documented in the author's talk:
* use synchronous exceptions (“precise-mode”), which means the faulted instruction cannot retire and cause damage
* re-tag allocations on free
This is the opposite of fun computing. This is commercial computing who's only use case it making sure that people can send/receive money through their computers securely. I love being able to peek/poke inside and look at my processes ram, or patch the memory of an executable. All this sounds pretty impossible on Apple's locked down systems.
They're not so much general purpose computers anymore as they are locked down bank terminals.
It's all fun and games until somebody else patches the RAM of your device, and sends your money away from your account.
More interesting is how to trace and debug code on such a CPU. Because what a debugger often does is exactly patching an executable in RAM, peeks and pokes inside, etc. If such an interface exists, I wonder how is it protected; do you need extra physical wires like JTAG? If it does not, how do you even troubleshoot a program running on the target hardware?
You disable mitigations for those processes.
So what stops malware from disabling the mitigations? This is the same issue that Firefox had re: requiring all add-ons to be approved and cryptographically signed by them. If it were possible to disable it it'd be useless. So 99.999% of firefox executables simply cannot run anything not first signed by Moz.
I think if you want to tinker with hardware, you shouldn't buy Apple. It's designed for people who use it as a means to an end, and I think that's a good thing for most people (including me). I want to bank on hardware that I can trust to be secure. Nothing wrong with building your own linux box for play time though.
If you like using debuggers, don't worry, MTE gives you a lot more chances to use them since it finds a lot more crashes. It doesn't stop you writing to memory though, as long as it's the correct type.
PAC may stop you from changing values - or at least you'd have to run code in the process to change them.
It’s a shame you’re getting downvoted because I think you’re correct, and this is a perfectly valid opinion to hold.
I would respond by saying that sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.
Computing hardware in general is way less expensive and more abundant than it used to be, so there are still many options in the marketplace for people to peek and poke into.
>sometimes I actually want a locked-down bank terminal (when I’m banking for example), and I appreciate the opportunity to buy one.
Yep, it's a valid use case. It's just not a general purpose computer. And it's a complete refutation of the ideals of Apple when it started out (see, 1984 commercial).
Bingo. None of this is for users. Apple somehow managed to put on a marketing mask of user respect when they’re at least as user abusive as anyone else.
https://www.theguardian.com/news/2022/jan/17/two-female-acti...
It's detestable how Apple handled the aftermath of this: https://en.wikipedia.org/wiki/FORCEDENTRY
The perpetrators were caught red-handed and let, go by Apple! This crime can, will, and has continued to happen due to the negligence of Apple's leadership. No doubt influenced by Tim Cook's obligation to the White House and their friends.If I remember correctly the Israeli government stepped in and seized all the material that Apple could use in the lawsuit, so there was no point in continuing.
If Israel can deter Apple so easily, that doesn't bode well at all for Apple's stance towards American surveillance.
It's just a private company. They only have power compared to governments in Cyberpunk.
A company who cared about users instead of its own profits wouldn’t do any of the things Apple does. Who’s really the naive one here?
This looks amazing, I cannot wait to see how attackers pivot.
https://xkcd.com/538/
I hate this comic because it is profoundly lazy, and I hate it when people hand-wave away meaningful security advances with it.
Hitting people with wrenches leaves marks that can be shown to the media and truth & reconciliation commissions. Wetwork and black-bagging dissidents leaves records: training, operational, evidence after the fact. And it hardly scales – no matter what the powers at be want you to think, I think history shows there are more Hugh Thompsons than Oskar Dirlewangers, even if it takes a few years to recognize what they've done.
If we improve security enough that our adversaries are _forced_ to break out the wrenches, that's a very meaningful improvement!
OK sure, but you don't really need to scale, just find the one guy with $500,000,000 in BTC that you want and hit him.
Again, lazy!
Yes: if you have half of a billion dollars in BTC, sure – you're a victim to the wrench, be it private or public. If you're a terrorist mastermind, you're likely going to Gitmo and will be placed in several stress positions by mean people until you say what they want to hear.
Extreme high-value targets always have been, and always will be, vulnerable to directed attacks. But these improvements are deeply significant for everyone who is not a high-value target – like me, and (possibly) you!
In my lifetime, the government has gone from "the feds can get a warrant to record me speaking, in my own voice, to anyone I dial over my phone" to "oh, he's using (e2e encrypted platform) – that's a massive amount more work if we can even break it". That means the spectrum of people who can be targeted is significantly lower than it used to be.
Spec-fiction example: consider what the NSA could do today, with whisper.cpp & no e2e encrypted calls.
This is great, since Oracle introduced SPARC ADI, into Solaris and their Linux SPARC workloads that I keep looking forward to "C Machines" becoming a common way to fix C language issues.
Unfortunately, like in many other cases, Intel botched their MPX design, only evolutions of MTE and CHERI are around.
The tagging mechanism reminds me of generational indices like https://floooh.github.io/2018/06/17/handles-vs-pointers.html, but I’m a bit out of my depth
1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas !
But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.
The problem with PowerPC AS tagging was that it relied entirely on the trap instruction. If you could control execution at all, you could skip the trap instruction and it did nothing. This implementation, by my reading, essentially adds a synchronous trap instruction after every single load and store, which builds a real security boundary (even compared to Android MTE, where reads would trap but writes were only checked at the next context switch).
Yeah, the security part wasn't baked into the hardware. It relied on the OS (it ran a virtualization layer of sorts) to enforce it via traps if it set those traps.
From https://www.devever.net/~hl/ppcas
> As such, they can principally be viewed as providing a performance enhancement for the IBM i operating system, which uses these instructions to keep track of pointer validity. It is the IBM i OS which enforces security invariants, for example by always following every pointer LQ with a TXER.
The big difference with this seems like it is an actual security mechanism to block "invalid" accesses where as the tagged memory extensions only provided pointer metadata and it was up to the OS to enforce invariants.
> Extensions provide no security. [...] The tagged memory extensions don't stop you from doing anything.
SPARC ADI was a predecessor to ARM MTE. ARM MTE has been available and used in production for several years now. ADI is also 4 bit but with 64 byte granularity rather than 16 byte.
That's interesting. I had no idea about SPARC.
From https://lwn.net/Articles/710668/
> If a rogue app attempts to access ADI enabled data pages, its access is blocked and processor generates an exception.
Yeah that sounds closer to ARM MTE. Thanks for the pointer
Nitpick: The AS/400 in 1988 didn't use the PowerPC. I believe it had it's own proprietary memory with tag bits included.
The first RS-64 with the PowerPC AS extensions came out in 1995.
You're right. That's a good point.
I wonder if these protections will apply to macOS as well.
The hardware for it isn't there yet, but I assume when new Macs ship it will be enabled there.
Once the hardware is there I don’t see why they wouldn’t turn it on.
Is MTE restricted to the newest (17) iPhone models or does it work on the older ones too?
Just the newest ones.
If we are checking every pointer at runtime how isn't this dog slow?
The chip does it by itself, in parallel to its other operations.
[flagged]
[flagged]
We move from the "prison phone" to the escape-proof "prison phone", and the spiritual abominations on hackernews celebrate.
More like Manufacturer Integrity Enforcement the way Apple makes things.
What’s the real benefit for regular/power users?
If you are targeted by advanced spyware then it makes it more difficult for their exploit to work.
Whether you like it or not, we are in an echo chamber. We will all benefit more rapidly once we figure out how to explain to an everyday Joe Blow why this technology is necessary in their daily life to get them hyped to upgrade their cracked XR/XS/11 barely hanging onto life support.
Meanwhile, Google is doing all it can to weaken Android safety by withholding images and patches, also by failing to fully segregate applications from each other. The evidence is linked below:
(1) AOSP isn't dead, but Google just landed a huge blow to custom ROM developers: https://www.androidauthority.com/google-not-killing-aosp-356...
(2) Privacy-Focused GrapheneOS Warns Google Is Locking Down Android: https://cyberinsider.com/privacy-focused-grapheneos-warns-go...
(3) GrapheneOS exposes Google's empty promises on Android security updates: https://piunikaweb.com/2025/09/08/grapheneos-google-security...
Look, I’m an iOS user but this seems like flame-bait to me without any technical details. I’ve seen a lot of Google blog posts about security improvements over the years so that seems like a very sweeping assertion if you’re not going to support it.
I haven't read the articles posted (and I don't know how credible piunikaweb and cyberinsider are) but here is the first-ish hand information from GrapheneOS: https://grapheneos.social/@GrapheneOS/115164133992525834
> ... Google recently made incredibly misguided changes to Android security updates. Android security patches are (now) almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access.. Google's existing system for distributing security patches to OEMs was already incredibly problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins.
> ... The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days. Moving in the opposite direction with 4 months of early access is extraordinarily irresponsible. ...Their 3-4 month embargo has an explicit exception for binary-only releases of patches. We're fully permitted to release the December 2025 patches this month in a release but not the source code.
> Nearly all OEMs were failing to ship the monthly security patch backports despite how straightforward it is. The backports alone are not even particularly complete patches. They're only the High and Critical severity Android patches and a small subset of external patches for the Linux kernel, etc. Getting the full Android patches requires the latest stable releases.
Recent discussion on 90-day embargo for security updates, https://news.ycombinator.com/item?id=45158523
That’s potentially substantial but I note that Graphene specifically rejected the framing:
https://xcancel.com/GrapheneOS/status/1964757878910136346
Yes, they said it was worse, i.e. affected all Android, not only AOSP, https://news.ycombinator.com/item?id=45161011