Earlier quoted context omitted.
Yes, but this breaks mirror mappings.
Can you elaborate on what you perceive as broken?
mremap?
Memory Integrity Enforcement
181–190 of 259 posts
Re: Memory Integrity Enforcement
#182Earlier quoted context omitted.
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-devic…
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.
Re: Memory Integrity Enforcement
#183Earlier quoted context omitted.
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 visi…
I don't really agree with your framing.
Re: Memory Integrity Enforcement
#184Earlier quoted context omitted.
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…
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.
Re: Memory Integrity Enforcement
#185> ...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. S…
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.
The idea is that a tag failure crashes your process.
Re: Memory Integrity Enforcement
#186Earlier quoted context omitted.
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…
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.
Re: Memory Integrity Enforcement
#187Earlier quoted context omitted.
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 deve…
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…
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.
Re: Memory Integrity Enforcement
#188Earlier quoted context omitted.
> 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…
> 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 (…
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 (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).
Re: Memory Integrity Enforcement
#189Earlier quoted context omitted.
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…
The choices they made are novel to my understanding.
Re: Memory Integrity Enforcement
#190Earlier quoted context omitted.
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…
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.