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.

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.

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.

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.

Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons.

> 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 mean, if you read the exploit chains, they apply to all iPhones and are wormable.

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.

Making attackers work harder is still a worthwhile goal. No security is perfect.

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.

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.

Yeah that’s really good.

That makes the probability work against the attacker really well. But it’s not a guarantee

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.

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

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.

The idea is that a tag failure crashes your process.

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.

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.

> That is, unless we balkanize our systems and services.

...all the way back to pen and paper

Google proposed it as DRM for web pages in 2023. After much outcry it was unceremoniously withdrawn.

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.

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.

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.

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.

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.

Presumably future M5 model Macs and iPads.

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.

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.

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.

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

Once the hardware is there I don’t see why they wouldn’t turn it on.

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.

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!

You disable mitigations for those processes.

https://www.theguardian.com/news/2022/jan/17/two-female-acti...

   >None of this is for users

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