Apple’s Memory Integrity Enforcement

Apple announced its new suite of memory security improvements from the top of the stack all the way to the bottom, so we dug through what they did and how they did it (performantly). 

Watch on YouTube: https://www.youtube.com/watch?v=9FJwOI2PliU

Transcript: https://securitycryptographywhatever.com/2025/10/31/apple-mie

Links:

- https://security.apple.com/blog/memory-integrity-enforcement/
- Secure Page Table Monitor and Trusted Execution Monitor: https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/1/web/1#secd022396fb
- https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/
- https://developer.apple.com/documentation/xcode/adopting-type-aware-memory-allocation
- https://security.apple.com/blog/what-if-we-had-sockpuppet-in-ios16/
- https://arxiv.org/pdf/2510.09272
- https://googleprojectzero.blogspot.com/2023/11/first-handset-with-mte-on-market.html
- https://developer.apple.com/documentation/xcode/adopting-type-aware-memory-allocation
- https://arxiv.org/pdf/2510.09272
- https://spectreattack.com/spectre.pdf

"Security Cryptography Whatever" is hosted by Deirdre Connolly (@durumcrustulum), Thomas Ptacek (@tqbf), and David Adrian (@dadrian)

Transcript

Copy

0:00

In the trust zone. Exactly. With white curtains? No, it's the other way around. In the white room with black curtains. have nothing to do with any of what you guys are talking about. Hello, welcome to Security Cryptography Whatever. I'm Deirdre, I am David episode. That's Thomas. Uh, every episode, and yet everyone keeps coming back. Yeah. we tried really hard to get a special guest for to today's episode on Apple's Memory Integrity Enforcement, and no one from Apple would come on our podcast, so we are talking about it. Um, to nobody. nobody. Yeah, no, it like it. This is a fool's errand, but, uh, we are trying to dig through this very cool innovation in low level, operating system security or system security. and all we have to go on is basically their long blog post. and so we're trying to go through what the hell is memory integrity enforcement. And how is it different than all this other stuff that's been deployed in say, Android or arm? so that's what we're trying to do. And just know Apple people. We know you're listening. We know you know who you are. We know that you know that we know who you are. And when we say things that are slightly inaccurate, you could have fixed this. Uhhuh. Okay. So this is the post that, apple released, uh, put out back in September This is an improvement that's getting actually shipped in iPhone 17, it's available now. Okay. I bought one for myself, but I accidentally shipped it to an address I don't live at anymore, and then had to cancel and refund it, and I haven't gotten a replacement yet since. Very good, very good OPSEC or something. okay, so this is this whole memory integrity enforcement is like a suite of things. basically it seems to be a bunch of improvements that they've already shipped to their kernel allocators and to their user land allocators. But also how they're actually managing memory much farther down in the stack. And some of these are becoming available to previous ioss and Mac oss and I assume, you know, vision OSS or whatever. but some of them are like explicitly because of the hardware and improvements, in the chips and the like, memory integrity and things like that, that like are specifically to the hardware that's actually getting shipped, from iPhone 17 and forward. and this is explicitly to try to improve the security posture of the entire system, against, memory, attacks, which tend to be some of the most, dangerous, costly in terms of the impact and the blast radius. but also are difficult. a lot of times on our podcast we've talked about, you know, write your code in a memory safe language. And a lot of these vulnerabilities are addressed by writing code in a memory safe language. But, you know, there's a lot of os code that's still written in non-member safe languages for very, for one, they're just been a lot of investment in there. you can't just like throw the baby out with the bath water and rewriting everything in memory, safe language, or the most important things in memory, safe language is, you know, either impossible, difficult, takes a long time, or you know, you have to pick and choose what those things are. But also there are things that you do and you are. Os and at like the lower than the OS level, like in your kernel and like at your bootloader level and, further down, you really need to like get your your hands grubby in. And you can't just, you have to be doing weird things with memory and stuff like that. So you can't just rewrite the world in rust. this is a lot of stuff that's trying to address that sort of, security posture, like deep, deep, deep in the stack. in a way that when you have full control tip to tail, top to bottom, of your system, they seem to be uniquely positioned to do. Okay. So, we're just basically gonna plow through this post and just branch out from there. iOS attacks, mercenary software, blah, blah, blah. Yes. Very important. And common denominator targeting using US iOS, windows and Android. They exploit memory safety vulnerabilities, which are interchangeable, powerful, and exist throughout the industry. I think the interchangeable thing is actually a really big deal. it's like a thing I think I like, it's a thing I think people are probably not gonna talk about enough. So are you saying that's like if you have your kind of spyware as a service service stack, you basically have something that you can deploy cross platform, and then you're like, cool, I'm on iOS, I'm gonna plug in this, but if I'm on Android, I'm gonna plug in this exploit and I think it's like, I think it's lower level than that. Now I'm, I'm, I'm talking out of my ass and extrapolating things that we like, talk to mark dowd about and things like that. Right? But I have no inside knowledge into how these shops are organized, But my impression is you've got like, um, you know, you've got individual vulnerabilities and then you have a whole stack of enabling software around the individual vulnerabilities in kind of the same way that you would have multiple sandbox breaks in Chrome, Like to get from one, area of the Chrome architecture to another, right? It is weird to call them components, or maybe they are components, I don't know. But there's techniques that people use to pivot from, one kind of exploit primitive to the next exploit primitive. And I think a lot of modern exploit development depends on kind of plugging and playing techniques, right? Like you've built code that takes like a write what, where primitive from, you know, point X to point y or this kind of type confusion to point X and point y, right? And in addition to just trying to solve those, to break those primitives directly, it's also valuable to make it so that every time you have a new vulnerability, you have to rebuild the whole stack of enablement stuff around it, right? So the path from the primitive to actually doing something useful, has to be built uniquely for every one of these things. Yeah, that makes sense. It also maybe. The case that like, that path is like the individual components within that path are also operating specific and not just in the, the like obvious location where like, you know, the part that gives you control of the windows kernel is gonna be dependent on windows. But like in a browser renderer process, if you can find like a privilege escalation through some syscall that is exposed to the render process, then you can like skip the step or you do like a browser sandbox escape if you can like go straight from say a render process to the operating system, but how your mechanism for doing that is gonna vary platform to platform. Okay. That makes sense. I wasn't sure what's the specifics were about interchangeable, but Yeah. That makes sense. Apple, improving memory, safety, swift, blah, blah, blah. In iOS 15, we introduced kalloc_type, a secure memory allocator for the kernel, followed in iOS 17 with its usual level counterpart, X zone malic, secure allocator. Take advantage of knowing the type or purpose of allocation so that memory can be organized with it. It makes exploiting most memory corruption vulnerabilities inherently difficult. So I think this is the stuff that's like getting back ported to earlier devices. if they can support 15 and iOS 15 and 17, well, it already exists in those devices, so it's not really getting Kal type is basically, an allocator that like, looks at the structures that are used in the kernel and then generates a type signature basically based off of the, uh, uh, the layout of the various fields in the struct itself. that's cool. and then only like. And then all, you have like various buckets that are used at the like page level allocation, and then you only put objects of the same type signature in the same bucket. So that like, you can't ever say, like have a object that has like an integer in the first eight bytes. Then be in the same bucket as an object that has the pointer in the first eight bytes, and then a bunch of like, stuff to make that actually work in practice. so the idea is that like in a use after free situation, you'd only ever be replacing the object with an object of the same type, which is presumably harder to exploit than an object of a completely different type. Mm-hmm. Thomas, can you explain what a use after free vulnerability is? You all know what a use after free vulnerability is Explain to our audience? Yeah, mean the name is pretty self-explanatory, but like why is it a vulnerability? I actually like didn't understand this until I worked on Chrome. I mean, I think the type confusion thing might be the simpl— like you just kind of laid out the obvious case, right? So like you. Especially in like complicated C and C++ code bases, like you're allocating memory and then explicitly freeing memory. And that happens in totally different places on the call chain. Sometimes. Like you might have something fire in response to a timer or something like that, right? So like this is a really pernicious class of bugs. Not even necessarily vulnerability. It's just bugs, right? Like you freed something when you didn't expect to free something and you held onto a pointer for it. If you induce those bugs deliberately, you wind up with. this dangling pointer, and in the best case, like the dangling pointer gets used and the program crashes because it's no longer mapped anything. That's what you want to have happen, right? But an attacker inducing this, will set it up so that, you freed the memory, you held the dangling pointer, and then it made a whole bunch of other allocations. And like really strategically with the allocation pattern picked what your dangling pointer will now point to. So in that situation, like, David was just saying, right, you had a struct, it had like two integers in the front of it, and now it has a pointer in the front of it, right? And like the code path that's holding that dangling pointer somehow responds to user input. You write to the integer, and by writing to that integer, you're writing a pointer instead of, you know, just the integer. So, like, you're kind of, you're using that piece of, you're using that piece of memory as two different types in two different locations in the code. Like the code is confused about what the type it is, right? And you are now rewriting a pointer out from underneath the code and you can have it write to a location of your choosing. This is, extremely valuable to an adversary who's able to just be like, you thought you were doing this, but I'm going to twiddle it and I get to make you do something you weren't expecting. Like, execute this piece of code when you weren't supposed to. And then you can, leverage that however you like it's a way of getting a write-what-where primitive, right? Usually a pretty constrained, write-what-where primitive of, I get to pick what you're gonna write and where it's gonna be written to. and that usually historically is game over and making that not be game over. I'm saying it's game over and it was probably game over in like 2011 and it's been not game over ever since then, but whatever. kind of one of the big things about MIE is making that not be game over anymore. Oh yeah. Making it not be game over. It's game over for the attacker. Ha ha ha. cool. So. Kay. Alec did its nice little thing inside the, the kernel. And then we have exon maek that's used by, you know, user land code. yeah, I would just add that even if you magically do this in the allocator, like doing that, this can cause weird shit to happen because like sometimes you just might want to like treat some memory of a different memory and maybe there's two pointers that are different types that happen to point at the same spot and then like stuff gets weird. Right? or maybe you want to change something out. For something else because it's the kernel and you're fundamentally doing unsafe things. like if someone does crap like that and just like a user land C program, it's, you know, it's 2025, you have permission to just go slap them. But in the kernel, like that's just kind of the way the world is sometimes. So just 'cause you have the allocator actually using it can be fairly complicated. Which Apple talks a lot about, in their massive Kal post from a couple years ago. Which, I'm just, I keep scrolling through because this is like the first time I'm looking at it. This is in fact ginormous and I am not a kernel hacker, so, I feel like type specific, like general purpose type specific allocator was new, right? Like not a super common, building program primitive, right? So you have like, um, you have protections on like a page-based level based mostly on allocation sizes, right? Like you could be strategic about whether, you know, and I guess you could put things in different arenas and manually in your code pick which areas things are coming out of all with the intent of trying to avoid that situation where the struct with the integer and the struct with the pointer at the beginning. Don't overshare the same memory. And then like, doing that at the level of a type thing, which requires compiler help. Mm-hmm. Mm-hmm. compiler help. Yeah. That's, that's, that's newish. Yeah. So Apple gets a lot of benefit here from basically controlling their own clang implementation, which they rely on to be able to do this in the kernel. there is a recent actual, CL and like c plus plus extension. typed operator knew that, I believe, I don't remember if LLVM like directly or if Apple or Google added it. Or some combination thereof, but like in c plus plus, instead of just overloading operator new, which takes a size T and it like gives back some bytes or whatever, it lets you overload operator new like a size T, and then a type T, which is like a 128 bit integer or something. And it just like, it's like, hey, you know, here's a random type information. Don't ask questions about it. Right? Um, I think there might be a way to provide it to define it yourself in code, but the idea is to make like a type aware global allocator, something you could do and use your land c plus plus code, but it relies on like c plus plus semantics of operating new. That's nice. I didn't know any of this. okay. I think that's like the first chunk of memory integrity enforcement, which is like stuff they already shipped basically. And it's the user land updates to ExOne Malick or introduction of ex Exxon Malick and the kernel land, chaotic type. keep in mind the total number of buckets here is limited. the whole point of the way they'd score the like structs is to try to minimize like impact of where like one thing's an in and one thing's a pointer. But there's an arbitrarily large number, at least in user land of types that you can encounter. And like at some point you have to start reusing buckets. So in 2018, we were the first to deploy pointer authentication codes in the A 12 chip to protect cont code flow integrity in the presence of memory corruption. This was very successful, with PAC behind us. PAC is like a goofy thing because like, well, I mean, it's not like I know nothing about P PAC. really hard to describe specifically what PAC does because it can be used as a primitive to just build like your regular control flow integrity, like forwards edge, backwards edge or, or only one of the edges. I never remember which one is which. and like basically it boils down to like, you replace like the function header, and assembly with like a pack where, jump and return. and you're supposed to get CFI out of it. And then there's like broader, but the like base concept behind pointer off is just somehow that like there is a signature. In the semi cryptographic sense in every pointer. And like that signature needs to be valid for the pointer to be valid. So if you're just dinking around with pointers, like your signature's probably not valid, but I mean, or it's like not valid in the right location. but I don't actually understand how it works specifically other than like there are people posting PAC bypasses, like there, there's at least one PAC bypass on Apple hardware submitted to Black Hat like every year, which is the same thing as CET, the like intel control, flow integrity. it helps, but like at the end of the day, like you can usually find a way around it. Okay. Brandon Aza had a talk about this in like 2020 blackout CET or pac. of PAC Bypasses. Okay. So that brings us to. MTE itself, or memory tagging extension, which is an arm specification that is technically in more things than just Apple devices. Memory, tagging, extension. MTE is from arm. It's independent of Apple. It's just a thing anyone can use for arm chips. I believe it's mandatory to implement in ARM 11 or ARM 10 or something like that. But like, nice, or it's not mandatory to implement, you know, it's a sign, not a cop, right? Like. I can't make you do anything. Um, yeah, memory tagging and tag checking system. Every memory allocation is tagged with a secret. this is sort of similar to the PAC signatures, except in the cryptographic sense. They're probably closer to MACs or whatever. Well, hold on. Like MTEM. MTE. Yeah. MTE tags are tiny. Yeah, MTE tag is just a four bit number. So you've got your 64 bit pointer and then somewhere else there is a four bit number associated with that pointer. That's your tag. okay. pack, pack signatures are larger, I thought. Right. Like one of the, like one of the, the, the, like the model pack bypasses is, finding a gadget that'll resign, you know, pointers, right? I just dunno anything about pack signatures, or whatever they're called. yeah, there's signatures. Okay, cool. I believe PAC is just using some of the high bits and the pointers, not actually making the pointers wider because that would like totally screw up everybody's code. Right? It's supposed to be transparent. Uhhuh, So I think you get like 16 to 24 bits of your 64 bits on an Apple machine, a reserve for pack, and then the virtual address space is like 48 bits. that's neat. Okay. So unlike that, MTE has four bits, that they have to be kept secret. But they are kept secret in the sense that they're like not in the pointer, right? They are somewhere else. They're associated with a pointer, but they're fundamentally like four bits of entropy associated with every pointer that in theory like you do not have access to and like the security model here is more like graph color. Like graph coloring than like signing things. Right. What you care about is a diversity of different tags, within the locality of a piece of memory. Like if you, you know, right. You know, right off the end of one thing to the next thing. You need the tags to be different and you need to not leak the tags. Yeah, the idea is that if you access, when you allocate some piece of memory, it will have some tag if you then free it. But the point, and it gets used for a new allocation, it will have a new tag and the used after free pointer will still have the old tag. And when you go to do something with it, the processor will compare the expected tag to the actual tag and then be like, oh no, crash your program. it'll crash your program if it's in synchronous mode. And if it's in asynchronous mode, it'll keep running your program and then crash it later. Hmm, okay. yeah. It will continue execution until there's a context switch I mean, I guess interrupt. Yeah, I guess that's, part of the whole async thing, Yes. Okay. much more performant.'cause you can delay the check till later and like keep executing the code and probably do the checks less.'cause like imagine you abuse the same pointer like eight times in a row to do something. Like you really only need to like check it the first time. Oh, okay. Async is like effectively free right's, what the graphing it's not, I mean, it's like a one, a little over 1% impact I think. Okay. then you can B. this has been something that's been around for a while, but like in the sense that it's been defined, but it just hasn't really existed in chips much. It's in pixel phones. I think it's in like pixel starting in 10 or something like that. eight pixel eight. pixel eight. And so you can actually go into Android settings somewhere and enable this. and apps that are like aware of it can leverage it. So if you turn MTE on in a pixel phone, like Chrome will run itself in async MTE mode. and in fact, this will happen automatically if you're in like the Android advanced protection mode on your device. and your device supports MTE, it will get turned on. And like Chrome, for example, will start using MTE in Async mode. oh, this is a developer option. yeah. So otherwise it's in developer option, but it's not on by default because like it's a battery hit, not just like a performance hit. So, And then synchronous classically has been very expensive. yeah. And then synchronous has been like, like double digit percentage expenses. But like, so graphene, for instance, graphene does synchronous in the kernel and async out of the kernel. And then I'm guessing that the intuition there is you spend most of your time in usual land, not in the kernel. So like a double digit percentage hit to a place where you're only spending a small percentage of your time is not that big of a thing. So you can be, and also there are much more fun vulnerabilities in the kernel. So there's a higher payoff. Yes. a 1% performance hit on the latest high-end phone is not the same thing as a 1% performance hit on an older phone or even a higher percentage hit on an older phone, that's probably a more realistic comparison. It's like, okay, it's a 1% performance hit here, but on an older phone it's actually a five to 10% performance hit. it can be easy to like be like, oh, I have a MacBook Pro, or I have a. A high-end Chromebook or I have a pixel, um, so I'll just take a couple percent here and there and trade it off. When, like, when you're not on the highest end devices, that can actually be much more impactful. I could definitely see that. Yeah. I just confirmed that. If you are enrolled in advanced protection and you are logged into your Google account, on an Android phone that supports it, it enables MTE for you.'cause I was like, I don't remember turning the saw on my phone. It's like, no, you did, but by can enable it on an individual device without enabling it on your your account. but if you enable it on your account and sign in, it will get enabled on that device. Yes. Yeah. That's how it happened. Cool. Okay, I'm going back, uh, that's general MTE that's been available to like broad armed devices in Well, I wouldn't say broad arm devices, right? There was like a spec for this, but it really didn't exist in hardware, for a while. It's never been in server software like Google jammed it into Pixel. We learned that, you know, apple put it into, some of their devices. but like it is not cheap. It is like a large percentage of the die area to put Oh. into a chip and it is not fast. Like there are other, there are other like things in this vein, like CHERI for example, that take like much less dye area. It's like a very small number of gates to add, CHERI. But, uh, you have to like do a code rewrite where you like, are like, all my pointers are 128 bits. Now let's see what happens. Um, for CHERI's also a bear performance hit, right? I'm not sure actually. I think it's smaller actually. It's just like you to make, use it effectively. You have to kind of define pointer domains and coach yourself. And at some point it's just like, dude, just rewrite it and rust. Well, you know, CHERI is supposed to, isn't CHERI also supposed to help mitigate, like Specter micro architectural attacks to a degree as well. It's not just about the memory safety stuff. I didn't think so, but I'm not sure I can feel Ben, Lori getting upset listening to this. CHERI supposed to be trying to address a whole host of up and down the stack, like CPU design, vulnerabilities, not just, the sort of memory safety stuff that, uh, I guess the MIE stuff is trying to address. so, anyway, M ds cord memory tagging. Check sec Chad. Memory tagging and tag checking system. this got deployed on Pixel. It's been available in some places, but there's costs. Apple conducted a deep evaluation and research process to determine whether MTV is designed would meet our goals Okay. We don't need to read. We don't need to read these parts of the Well, I'm getting back into it. We went to fucking Apple applied the fame and method to MTE and came up, thought real hard about the problem and came up with EMTE, um, which is basically, the iPhone, which has never been compromised before, now has groundbreaking new protections for the things it was never nevermind the fact that there's no malware at all on iPhone anyway, here's an entire post explaining how we're patching security holes on the iPhone. apple doesn't really say what EMTE does beyond like, it's just MTE in synchronous mode and fast, Hold on. So my understanding is that EMTE is just another name for MTE four. Right? Which is a set of like four MTE extensions. It's canonical pack checking. It's the one they list in the blog post. the one I list in the blog post is like your global variables, or I guess your tech, your BSS or whatever the data segment is or whatever, right? Like you have variables that are not in tagged regions, right? And in standard MTE, those aren't, there's no checking for that. And in MTE four, I don't totally understand how this works, but there is checking for, memory accesses that transition from a tagged memory region to an untagged memory region. So like, in theory, it should automatically detect, right? if you're running off the end of a tagged memory region into untagged memory, then the tag has changed even though the new tag is nil. And I guess that wasn't chucked before and now it is with MTE four. Hmm. So this is the arm docs for that, that the apple linked, canonical tag checking reporting all non-ad address bits on a fault store only tag checking and memory tagging with address tagging disabled. I thought we already had store only tag checking, or maybe I just don't know what store only tag checking is, but I was saying earlier that graphene does like the kernel of synchronous and then the, the usual end is asynchronous. But there's also a thing with them where, like reads are synchronous and, writes are asynchronous, which I, I thought that might have been what store only attack checking is. I don't, I don't know. Fuck do I know So we have a few more capabilities around MTE itself with MT four slash e mte, and then more importantly, whatever they did on their chips in conjunction with the capabilities in MT. E four We're coming up on my, done fast. we're coming up on my favorite section of this post, or my favorite sentence in the post. Just like consider that you could do either AY or synchronous mode. Synchronous is the good mode and asynchronous is the bad mode We could have implemented asynchronous. We would not implement such a mechanism. Apple, please run these things by me. Now, just to baseless the writing, you know, as someone Apple who's like been making their own chips for years, you could imagine that presumably they didn't, this isn't their first iteration of, you know, MTE, right? They've presumably been experimenting with this and just like not turning it on. Like, I can't imagine this is the first time they ever taped out some of the chip that is required for MTE, which suggests to me that at some point someone might have implemented such a mechanism, they just didn't tell us about it. it. all they had to do was use a different verb there. They could have just said, we didn't implement such a mechanism and it would've read fine, but they wrote, we wouldn't, which reads so weird. So weird. Um, what you mean by implement, which in this very, uh, very massage, public facing texts might mean implement and deploy and ship. I want to call out here that the Graphene Project, who, by the way, if a graphene person listens to this, we would very much love to get you on and have you go through a dramatic reading of this with us and then call out.'cause look, you, you hear us? We don't know what we're talking. David knows a little bit about what he's talking about, but I don't Right. We could use the help. I wanna call out though that the graphene project, there's an angry thread that, responded to this thing. I won't read that whole thread, but it's worth reading. And they say that there's basically no difference that they've seen in terms of breaking exploits by having ay versus synchronous. Like to them ayc is enough. Okay. Depends on how much you care about what graphene thinks. I wanna say I care a lot about what graphene thinks because I would like research from Project Zero suggests otherwise, depending on the setup that you're in. Interesting. is what it is. the thing about MTE generally and then particularly about async, right? Is that like you have, so you have four bits, of entropy with the pointer. And in some cases, like let's say you're a web browser that runs like arbitrary JavaScript, depending on what the behavior is. When, like in the failure case, like if you can just run your exploit 16 times and then you know, have a more likely than expected value of having it be successful, one of those times, if all of the other 15 times are like a huge disaster and you can't actually write that loop, like maybe that's a problem. like if you're able to just do it in the background and like no one's really the wiser somehow by like. Having some JavaScripts that then like loads another page that tries it 16 times. So that, like that process that you never see is the one that dies because it's whatever. Then, um, then suddenly like, you know, MTE is not like this be all, end all. it's much more useful in a situation where you only get one shot at it or a limited, um, number of tries or a limited reaction time to it. And the more shots you get at it or the more instructions you get after it fails, like the more likely it is that you'll be able to, can cock a situation in which you can get a tag match and then can do something bad. Mm-hmm. but that's all gonna depend on like, you know, what your program mm-hmm. and of course like web browsers are stuck with the hardest mode of the problem'cause they're like, let's just run a bunch of code from arbitrary sites and like isolate some of it per process And some of it like within the process. yeah. Oh, poor web browsers And it can all change dynamically. You don't even get a canonical version of the code to download before you run it. downloaded that webpage two minutes ago. Fuck you. You don't get to rely on that at all. Apple says. That always on synchronous MTE across key attack surfaces. While preserving a great high performance user experience is extremely demanding on hardware well lucky Apple, that they seem to be very good at designing fresh brand span new hardware to do everything they need to do. MT for M-T-V-M-T-E to provide memory safety in an adversarial context. We need to finely tune the os, define new semantics and the confidentiality of memory tags on which MTE relies, to do what we think we need to do. We would carry out a massive engineering effort spending all of, All of Apple, apple silicon operating systems are software frameworks. Excuse me. I think there's some computers in Apple that run in the cloud, the Apple cloud. That, that they were not listed in that list there, so citation needed, okay. With the highly successful secure memory allocator work that we've talked about before, transform MTE from a debugging tool into a new security feature. And so the thing that they're calling memory integrity enforcement, includes the new memory allocators in the kernel and end user land enhanced memory tagging extension in synchronous mode, and extensive tag confidentially enforcement policies. We haven't talked about that at all, and I don't think, I think that's down at the bottom. We have to get to that. and it's built into Apple hardware and software and all models of iPhone 17, iPhone air. and I think they said in their announcement that it's gonna come to either the next MacBook or the latest MacBook. I forget which one. soon. Cool. And it seems like the real win here is doing all of these things together. And the novel thing that they did is updating their M chips or their a chips or whatever to be able to do all of this and not like crawl on all the time. Synchronously always. And not crawl the os to a halt. They were able to make all these improvements, to do all this stuff all the time. and it's still a performant iPhone and it's not, you know, killing your battery, basically. and that's a thing that Apple is in a unique position to do, to do well. I think that like, that's the, actually the big takeaway is that they're doing it fast. Like all of this stuff has existed for a while and is like good. It's, it's effective, but it's not like a hundred percent effective and it's been in stuff for a while. Like not just, just Apple, right? Like Chrome has had partition Alec for a number of years now, which is another user land allocator, that basically does ref counting and then zaps the memory once the ref goes to zero in such a way that if it is used after freed, you end up with a crash. that only works for heap pointers. It doesn't work for all pointers and you have to make source level changes that can't be automated, but it can be done. Mm-hmm. you have that stuff in other places. You have had asynchronous MTE on other devices. The real takeaway is that like they bundled all of this together and made it fast such that they like turn it all on by default everywhere. Mm-hmm. Alec is on in like most of Chrome, but it's not on like everywhere. Everywhere, for example. Okay. Yep. so they're reviewing the memory allocators. Are you familiar with Lib Pass Web kit's, web Pass? I believe it's just their way of basically doing like per object heaps at like the type level. Um, but yeah, it's just like a c plus plus e version of, of doing the like type based allocations. all use type information to decide how to organize memory allocations. so if those are all c which is not strongly typed, Lib has a c plus plus Okay. All right. The other two are passing more information about types to the compiler to actually like, be able to use the type information to do the layout and allocations and all that sort of stuff. Yeah, I mean, I think all of these required like some amount of compiler extensions to make work in practice you just have to free outta the bounce. Bugs overlap. Yeah, go ahead. I was say, speaking of compiler extensions, I don't think they cover this in here at all, but there's a couple other compiler extensions that, um, apple has driven and LLVM that have been adopted outside of Apple, including Chrome for basically, um, tagging, um, like in CA common pattern as you pass a pointer in a size parameter. and basically at the compiler level ensuring that like that size parameter is in fact enforced and that like there are checks. just like you would if you're using like stood array or stood vector in c plus plus that like you, you annotate, the, the function call and then the compiler puts the bounds checks on the, on the pointer, a accesses to make sure that, um, you don't have, uh, spatial memory on safety. and then also like corresponding, compiler passes if you don't want to enforce that just for detecting, um, when it happens. So you can like ban new uses of, of just like unsafe pointer accesses and see, um, also very effective and can be like slowly rolled out over a code base on like a file by file basis. You can be like, no more raw pointer accesses in this directory, aside from the existing ones. nice. I haven't heard about that at all, but I am not paying very close attention to that side of the world F bound safety or something like that is the flag for clang. Cool. And so like, this is sort of stuff that's been kind of going on for years and they're taking advantage of it for this, and then they've already rolled out these, improved allocators. and to their credit, they were driving a lot of it too, right? Like they have a lot of clang developers Yeah. Well, I'm not surprised, and they used to have, what's his name, who like created LLVM, Chris Latner. Cool. Yeah. That's a, that makes a lot of sense. okay. Tpo wear placement policies over secure memory allocators helped work memory corruption, Okay. Yes. Does not, does hit performance. performance is either even as the same or better. Allocators can apply protections only at the granularity of memory pages 16 kilobytes on iOS. for smaller allocations, secure allocators can use page level protections to help prevent memory corruption attacks across different type buckets. However, page level protections are to coarse defending as attacks within the same type bucket. And we use memory tagging to close this gap. So it's not just like, cool, we do stuff at the allocators and then we do memory tagging, you know, as well. It's like, no, no, no, we have to cover. The page level and cross page stuff. We, via our kernel level and user land level memory allocators because, and then we also have to do the memory tagging stuff because like there's fine grain stuff that is not covered by the page level memory allocation protection. Cool. All right. And that's where the EMT is comes in to be And to be fair, that's like most objects. Okay. most objects are smaller than the full 16 kilobyte page. Not out, out here allocating pages. Um, EMT protects against two of the most common types of memory corruption, buffer overflows in use after free, which we talked about. But for overflows, allocator is responsible for using different tags for name allocations. If a request to access memory spills over to adjacent memory, it has a different tag, the hardware blocks it, and the operating system can take action and terminate the process. Yeah. Yeah. This is the easiest one to get your head around. where they diagram it and we covered it earlier, they have a nice diagram with emoji and colors to show how MTE works. It's not very complicated to understand the core concept. We will save you from explaining the diagrams. Um, uh, wait, that's, yeah, that's the buffer overflow where you're just going over the type over the area. And this is the one where you're, using after free. diagram both bound safety and spatial safety and then, temporal safety, which would be use after free, Which like my intuition for the use after free MTE story, it's like you can free the pointer along with the actual memory. Nice. or less. Yeah. I would also just say in modern, projects, there can be spatial memory safety errors, like when. First learn about memory on safety. I feel like buffer overflow is the main thing everyone learns, but like in, in practice it's not that hard to mitigate the like 99% plus of your spatial safety things by like, I using containers and c plus plus, using F bound safety, writing sane c code without like limits where you access things like having a SPAN class or a span dropped or whatever you call it. Like, is, is fairly common. And, and like enforcing everybody uses that. Like, you get pretty close to very high coverage of like your, your spatial memory safety, at least when it comes to containers. Um, not necessarily like a crap on the stack or mm-hmm. lifecycle is a nightmare. yeah, lifecycle is a nightmare. So in practice, like the most memory, safety, vulnerabilities that matter, they're all used after freeze because like we understand how to write a container these days and make it. It's the ones where it's like, okay, we've handled all of those. It's like, okay, later in the lifetime of this piece of memory or whatever, it either got used, when it was supposed to be already freed or something to that effect, because you can't just like write a container around it. they're intrinsically inter procedural lifecycle vulnerabilities where spatial ones aren't necessarily like, all you have to do is store enough information with the data so that whatever loop you're doing or whatever right you're doing into it, can just check to see if you're within bounds or whatever. But a lifecycle vulnerability could span, 15 different functions called the different times. Yeah. Okay. you can enable like hardened lib c plus plus, I think with a pound f or maybe a compiler flag or both. Um, that just like puts checks everywhere in, in like the CC plus plus standard lib, for example. Um, 'cause like by default only some of the methods actually like do check access. it was less so that like we didn't know how to do this for years. It was just like, oh, well the performance impact of putting the checks everywhere is too high, so we can't do it. We'll assume the programmer put it in the right spot. But like, what actually happened, like is like some people got hardened lib c plus plus and the lib c plus plus Chrome enabled that like years ago at this point. Um, and then eventually, like some other people followed as well and like that got the compiler people looking at it. Then the compiler people were like, oh, actually we can write a ton of optimizations for this because like most of the time that you insert checks, like you can, like deterministically prove you don't need to do the check because you did the check earlier. This happens a lot in like rust with Iterators and stuff. Like the vast majority of the checks end up getting optimized out by the compiler, because they're redundant. and so like once you actually put it, the effort into writing those optimizations. Then the harden mode gets faster. But we had like this chicken and egg problem for a while where people were like, we can't use harden mode 'cause the compiler doesn't know how to optimize it. And then the compiler people were like, we're not optimizing that 'cause no one's using it. this. And it was just like, oh, well actually with like a modicum of effort, like a year of effort from a compiler team at a big tech company, like you can reclaim like the fast ma, the like 1% performance loss or whatever you got for, hardened c plus plus Yeah. okay, we're, we're trying to zoom through this so we can wrap up before, we all have to disappear. weakness of original MTE access to non-tech memory, global variables not checked by hardware. this is nice for attackers. I don't get this. There's a thing I don't get about this, right. Which is like, so the, the mitigation here is that attackers have to know the tag of the region that they're coming from. Now to do this, we're talking about writing into untagged memory, right? So what is the actual pattern here? This is just a thing where like, I'm sure this is obvious if, if you've looked at an exploit or whatever, but like, what does it mean to know the region's tag from like you're writing from an untagged to a tagged region. What does it mean to know the tag of the, of the tagged region? Do any of us know? I dunno, I mean, it's presumably that when you're accessing the global variable, you're doing so from some location and code and that location has a tag and you need to like know it yourself, I don't know what it would mean to actually tag the like instruction segment or like what that mean, or like, is it, is it all sent through a function pointer? Then that function pointer as a tag Because the function pointer is in the, whatever the non-data segment is called. I don't remember. It's like the centerpiece Of how they're describing EMTE. Well, I don't believe in reading assembly. So, so beyond global variables, they also talk about trying to mitigate, specter or, Oh right. the, the other common bypass for MTEs to use some sort of speculative execution side channel to read out whatever the tag is and then on your first attempt to like overwrite you just use the correct value. this is and they say they mitigate this Yes. With tag confidentiality enforcement, which they, back using their secure page table monitor, which I think is something along the lines of an armed trust zone or Intel, SGX, um. all we know about No, we know a lot. No. We know a lot about the secured page, stable monitor, there's a paper about it that kind of unwinds the whole thing. Works out what all the function calls Oh, this, this one. Yeah. We'll throw this in the notes. and great job. To the authors of this paper whose names I will slaughter, paper from, did I find that paper? Was that paper released like seven days ago? maybe, 10th of October, 2025, current revision. 12 days ago. yeah. And that's V one. Hell yeah. so I guess they were, we were not the only people intrigued by, uh, intrigued by this blog post in reference. perhaps, although this looks like it's also a master's thesis, so maybe they were starting long before. the vibe is that you're running a big chunk of the virtual memory subsystem of the kernel in like an enclave. Mm-hmm. I guess so. my understanding was the driving purpose for this originally was kernel exploits that would bounce off of gadgets that would change the page tables and stuff. Mm-hmm. Like you just, you've got control over memory in the kernel. You can bounce around, you can just flip things to be executable or not executable, whatever. whenever anyone mentions a trust zone, I just immediately think of it in to the tune of the song, white Room. In the White Room, but I wanna say cream, but In the trust zone. Exactly. With white curtains? No, it's the other way around. In the white room with black curtains. have nothing to do with any of what you guys are talking about. We need to educate you on your classic proto metal we need to educate the oldest person in the chat on music that came out before we were all I was born. Yeah. Okay. So those are the three main pieces. Then we've got the improved type informed allocate, secure allocators. we've got the enhanced extended memory tagging, extension, whatever. And we've got, this whatever tag confidentially enforcement, which is basically they're storing all this stuff in their, their trust zone t type of deal that they already had, the secure page table monitor. and that's based, that's it. that's memory integrity enforcement or whatever. cool. Let's see. And then they prob they of course aren't going to say the specifics of how they made all of this fast enough, but that is like the secret sauce of like how they're able to ship all of it in the first place. Evaluating pointer authentication instructions, speculatively. Yeah, that's, that's Specter V one, right? Yes, that's Vector V one, which was basically never fully mitigated. We just kind of were like, eh, it's probably fine. We'll split stuff at the like, like the kernel will deal with it if you care about it at a per process level. And if you know. You care about it within a process, well just split your stuff into multiple processes, right? Like that. That's what the usual mitigation is, is like figure out what your security boundary is and then, you know, cut it. it. Yep. is why like Chrome has site isolation. Well, there's a number of reasons why Chrome has site isolation, but the best mitigation for one site can speculative, speculatively read private data from another site. In the same process is to simply not put two sites in the same process. same process. Yep. And this is like, if you really care about Specter V one. Just run that process on like a core that you trust that you don't share with other processes from people you don't trust, uh, and you're, you're good to go. That's a bit expensive and getting that isolation is, is kind of difficult if you like to have run things on a cloud, uh, hypervisor. Oh, sorry. Money, please. let's see if we can cover the rest of this real quick. Okay. Specter to cover. No solution to this problem, blah, blah, they addressed Specter with the secure page, table thing that we just discussed. And then they're protecting their users with memory integrity enforcement. Um, and that user does not involve me because of my aforementioned inability to input the correct address when ordering a phone. Protect all users by defaults and yeah. Google took a great first step last year when they offered MTE, those to opt in. Good for them, but technically into MTE without opting into the program for at-risk users. But yes, it's been on the phone for a number of years at this point. you. Just, you just have to go in and you have to tap like the version number of Android like 15 times and turn on dev options and flick a bit. But you have to opt, you have to opt into it unless you are in the Advanced Protection Program. Uh, but even so limited by lack of diva integration and the opportunity system, blah, blah, while Deirdre figures out if there's anything left in this blog post, which I don't think there is, the other thing that I would add is that this is all arm stuff. Which brings us to like the elephant in the room of X 64. so like X 64 right? Is like a MD and Intel and they have some sort of like intracompany board that like sets what the instruction set is, right? Because it was basically an instruction set written by AMD to look like Intel. they are still discussing what the instructions for MTE would even look like on X 64. So for all intents and purposes and the, the like near to medium future, you should not expect like MTE on any any X 64 devices. so this is really like an ARM 64 thing and a subset of arm 64 thing. And so like, it's not clear like these are good hardware features to leverage when you have them, but I don't think they take away from the need. To like write things in memory safe languages as much as possible to like fully mitigate the underlying uh, um, the underlying problems, um, where possible, right? There's still edge cases with that. Like what happens in your program writes out other code into the process and, uh, is a JIT. And that has logic bugs where it writes out the wrong code, right? Like memory, safe languages don't help, rust, it doesn't help you there. Mm-hmm. hopefully you know that these are all things that can happen in parallel, um, and should all combine to build a better system. Yes. but in no world can you assume that like your software will only run on, on, um, a device that will have MTE unless maybe you're like, um, apple in like five years or something, Yeah. And even we'll see if they even do like emulation stuff still.'cause they still have the old stuff and they still have a bunch of apple silicon. So yeah, you, you won't even have that, even if you're Apple for a long, long, long, long time. and like we said, it is, there is a probabilistic element to all of this. It's not deterministic, and so Mm-hmm. it may be the case that we figure out ways to make that, one in 16 chance your exploit works to be much higher. Or the lower, the chance that it works, lower it works to be much higher, right? Like Oh. right. It could be the case that we figure out like, oh, it turns out there's this one cool trick to double your likelihood of guessing the tag on the first try, Okay. So basically the lowest chances for the attacker are right now because this yeah, one in, one in 16. yeah. They could only get better. Yeah. Okay. Use the secure allocators first. Use extended MTE to protect smaller individual allocations within the type bucket. And then knowing where and how we should deploy EMTE, we could accurately model the tag checking demand of the OS and design our silicon to satisfy it. So yeah, knowing, being able to bleed through or look through all these layers of abstraction and control it, um, control, your designs on both sides allows you to optimize. our hardware implementation influence additional software design decisions, reducing overhead of tag extracts even further. And like, this is the power that you get by having a full vertically integrated system like this is that you can do all of that optimization work to make all of this work, on by default and ship it. And it isn't a performance cost, it's actually like, it's, I don't know if they have any numbers, but it's definitely not slower. And I don't know if it is slightly faster than the previous generation. but it's definitely not slower, which is not for all the other instances is not the case or equivalent deployments of MTE so far that are not Apple, that we're aware. Aware about. Okay. And then checking how secure it is. any developer can begin testing the protection including EMT on hardware that supports it using enhanced security settings next code. So if you're a dev, you still have to opt in. but I would also note that, it's kind of, when it comes to web browsers, it's basically safari only because Safari is the only, like the web kit is the only underlying, browsing engine on, iOS. But why don't we, they have a, a diagram or a table further down describing, How it breaks various real world exploit change chains. they have a big diagram here. for, three iMessages change a safari chain and some kernel stuff about where it gets either blocked by a secure allocator or blocked by EMTE or somehow blocked by both. that's like I, I think some of the secure, like, it's not clear to me like this isn't necessarily a fair way of looking at things in the sense that like, all of these exploits were like, no one's doing extra work to get around a mitigation that doesn't exist at the time they wrote Yeah. like, you can be like, okay, you know, we've reversed this chain from whatever, and determined that like, nowadays this would be broken and like. Four or five of eight steps. but like, what does that, what does that really mean? And so I, I think the notable thing for me more in, um, this graph is just like, how far to the right is the EMTE, um, uh, circle or, or icon indicator, um, in each of these chains? Um, and like the, the further to the left, it is, I suspect the like more, um, more effective E-E-M-T-E is, right? Like And so we've got one kernel, LPE where it's very far left and then we've got a mess, iMessages chain or messages chain and that's it. It's pretty far right for the rest of 'em. Whereas like the allocators things, I almost look at like the opposite direction where like if a allocator change blocks something very early on, it's just like, okay, well they weren't thinking about it at all. Versus like something like EMTE is more likely to kind of like cut off the base concept. Um, but who knows? yeah. Cool. I like this. It's, informative. It's, yeah. Cool. Nice stuff. Apple. Apple, I think has a team that's called SEAR and a team that's called Spear, and they're both in the security team. And I find it confusing. Yeah. And this post was by seer. I don't know what SPEAR stands for. Platform, software I don't know what either of 'em stand for. for. Yeah. SEER is, I know is people join them and then you never hear from them again. They disappear. SEAR, security, engineering and architecture. I assume. Eventually what happens is everyone that joins either of those teams eventually accidentally walks into the glass exterior wall at the apple UFO building that they like didn't see because the wall is glass and clean. and it like gives them amnesia and they, how to interact with the rest of industry. Uhhuh Apple's doing its damnedest to be like, no, really, we're very, very secure. Uh, phone. You by our phones, so we'll see if anyone introduces, uh uh. Some sort of hardware fault isolation for securing things like JITs in the future, but That'd be nice. Cool. I have a whole blog post about that if you're interested. security, cryptography, whatever is a. Oh yeah. Cool. Security, Cryptography, Whatever is a side project from Deirdre Connolly, Thomas Ptacek and David Adrian. Our editor is Netty Smith. You can find the podcast online at scwpod. And the host online at durumcrustulum at tqbf, and at davidcadrian. You go by merch online at merch dot security cryptography whatever dot com. If you like the pod, give us a five star review wherever you rate your favorite podcast. Thank you for listening. Yay.