Posted by circuit 3 days ago
>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
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.
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.
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.
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.
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.
Qualcomm has to make their own implementation which has significantly delayed widespread availability. Exynos and MediaTek have it though.
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.
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.
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.)
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.
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
The business model of Pegasus et al. will be gone.
I got a bit confused when reading this. What does it mean to "know the tag" if the memory region is untagged?
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.
Did they ever explain what that mitigation does?
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)
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.
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.
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...
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.
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.
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 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?
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).
* use synchronous exceptions (“precise-mode”), which means the faulted instruction cannot retire and cause damage
* re-tag allocations on free
They're not so much general purpose computers anymore as they are locked down bank terminals.
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?
PAC may stop you from changing values - or at least you'd have to run code in the process to change them.
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.
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).
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.
>None of this is for users
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.