Memory Integrity Enforcement

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!

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.

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.

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.

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.