Sam BushellSep 10, 2025
Allison Husain

Memory Integrity Enforcement is the culmination of a truly incredible amount of work :)

While there's so much to love, one of my favorite pieces was getting to bring kalloc_type-style isolation to out-of-bounds accesses on both the architectural and speculative path. This lets us both mitigate a variety of Spectre v1 style attacks and break the reliable exploitation of some of the most powerful first-order memory corruption primitives (arb offset OOB R/W).

https://security.apple.com/blog/memory-integrity-enforcement/

Memory Integrity Enforcement: A complete vision for memory safety in Apple devices - Apple Security Research

Memory Integrity Enforcement (MIE) is the culmination of an unprecedented design and engineering effort spanning half a decade that combines the unique strengths of Apple silicon hardware with our advanced operating system security to provide industry-first, always-on memory safety protection across our devices — without compromising our best-in-class device performance. We believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems.

Memory Integrity Enforcement: A complete vision for memory safety in Apple devices - Apple Security Research
Sep 9, 2025 at 6:50pmWeb
Show threadAllison HusainSep 9, 2025

/2 The trick behind this mitigation is to use the compiler to clamp all pointer offset operations in kernel code to a magnitude of less than 4GB. If you feel like grep-ing, the specific codegen for this clamp operation currently uses a special 0x2BAD poisoning pattern in the top 16 bits when the magnitude exceeds 4GB.

With some VA layout tricks to inject large 4GB unmapped gutters between major kernel VA regions, this has some delightful consequences.

Show threadAllison HusainSep 9, 2025

/3 For example, a first-order arb offset OOB write in a kalloc_type submap can now only target the per-boot random set of types on that same submap front, which can make exploiting what used to be one of the best flavors of bug quite hard.

This is even more fun when considering the data submap where an arb write is now restricted to targeting only other data allocations. Any types (eg. pointers, indexes, etc.) you could target to escape the data heap are themselves patchable security bugs :)

Show threadAllison HusainSep 9, 2025
/4 and, best of all, these same properties work identically to mitigate arb offset OOB Spectre v1 gadgets in a way which is performant enough to ship in a consumer product. This lets us defend MTE tags in the kernel against Spectre V1 by forcing attackers to deal with type isolation in order to leak the tags they need to further their memory corruption related attacks.
Show threadAdam Bell Sep 9, 2025
@ezhes_ really really nice work
Show threadJason Bowen 🇺🇦Sep 9, 2025
@ezhes_ I'm not a fan of Apple on FLOSS grounds, but this is really interesting work!
Show threadGarrettSep 10, 2025
@ezhes_ Thanks, this part wasn't clear from the blog post. What incredible work by the team, and bonus humor points to someone for the poisoning pattern 😁
Show threadGabriele SveltoSep 9, 2025
@ezhes_ fascinating stuff. It's always interesting to read about these kind of multi-layered defense-in-depth mechanisms.