Huge 
from Apple available with new A19 chips.
Sadly they seem to only enable it on select components, not globally like GrapheneOS does with MTE, but appears to be a more robust implementation.
10 Likes
so not even the A18 gets chips get that? what a shame
cool yes but come on.
MTE requires hardware support.
I thought MTE was standard in ArmV9.
Still no reason not to have it in the A18 Considering the only modern and widely available budget option from Apple currently is the 16e, otherwise you’re leaving users shelling out 800 dollars for this, when they could shell out less (600 to be precise) and still get MIE (or Apple MTE) instead
Can someone please ELI5 as to what this is exactly? I don’t want to misunderstand.
Memory safety bugs make up a substantial amount of all security issues, technology like MTE with integration via eg. memory allocators can largely mitigate them entirely.
1 Like
So a big win for iOS security? Got it. Thanks! Glad to see Apple continuing to innovate here.
Android originally supported MTE as a developer an opt-in for apps, and later enabled it more so when Advanced Protection was enabled.
GrapheneOS has made more substantial use of MTE support for the Linux kernel, the default system components, Vanadium, and user opt-in for user apps since the Pixel 8.
While Apple’s implementation does appear more robust with regards to tag security and likely performance, it is largely the same underlying tech.
Apple also appears to be using it in the stricter synchronous mode whereas GrapheneOS uses it in the synchronous mode for the kernel and the asymmetric mode (sync for read, async for write) for userspace.
But again it seems Apple is very selectively enabling it for performance compared to how much GrapheneOS utilizes it. Hopefully Apple will enable it more widely when eg. Lockdown mode is enabled.
6 Likes
TIL. Good to know. Thanks for the context and info!
Do Pixels not use the last version of MTE (EMTE)?
No, EMTE is the latest 4th revision, Tensor uses the 3rd revision afaict.
1 Like
If you want even more context see here
4 Likes
Another relevant article:
Apple seems to be claiming the components that aren’t protected by EMTE are already protected by their secure software memory allocators, so that their memory safety work that doesn’t strictly require EMTE can benefit users of older devices… Is that a worse approach than just blanket enabling it?
Or are you mainly referring to third-party apps? I am interested to see how many developers opt in to using EMTE, and whether Apple will enable it systemwide with Lockdown Mode…
Wouldn’t it be moot for Apple to do this and not enable this system wide in Lockdown? I would imagine they would but Apple thinks differently often so can’t say with certainty.
It certainly seems like they should enable it in Lockdown Mode given that they say:
Google took a great first step last year when they offered MTE to those who opt in to their program for at-risk users.
2 Likes
I’m betting on they will. It would be very odd if they don’t.
I mean if the impact to performance is not notichable, why not go for security in depth.
That is basically my question, I guess. If it means they’d focus less on non-EMTE tools essentially using it as a crutch I can see why they’d want to avoid that, maybe EMTE would cover up flaws in their other tools they’d otherwise not discover.
I also don’t know how robust or complex their other memory safety systems are, so the likelihood that they’d even be exploited in a way that additional EMTE could prevent in the first place.
The most obvious reason is performance, which is why I suspect they will do both and have defense in depth for Lockdown Mode users, and will take this current approach for regular users. It’s just not clear to me how far behind that will leave regular users, which do still seem to benefit from broader, non-hardware-based protections with these changes.
