Apple’s Memory Integrity Enforcement

WEBVTT
00:00:00.299 --> 00:00:02.310
In the trust zone.
00:00:02.729 --> 00:00:02.970
Exactly.
00:00:02.970 --> 00:00:04.679
With white curtains?
00:00:04.679 --> 00:00:05.610
No, it's the other way around.
00:00:05.637 --> 00:00:07.302
In the white room with black curtains.
00:00:07.602 --> 00:00:09.587
have nothing to do with any of what you guys are talking about.
00:00:14.740 --> 00:00:17.798
Hello, welcome to Security Cryptography Whatever.
00:00:17.798 --> 00:00:21.893
I'm Deirdre, I am David episode.
00:00:22.509 --> 00:00:23.469
That's Thomas.
00:00:23.829 --> 00:00:27.189
Uh, every episode, and yet everyone keeps coming back.
00:00:27.579 --> 00:00:27.998
Yeah.
00:00:28.478 --> 00:00:41.139
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.
00:00:41.649 --> 00:00:42.753
Um, to nobody.
00:00:42.904 --> 00:00:43.033
nobody.
00:00:43.393 --> 00:00:44.609
Yeah, no, it like it.
00:00:44.609 --> 00:00:58.183
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.
00:00:58.664 --> 00:01:02.624
and all we have to go on is basically their long blog post.
00:01:03.164 --> 00:01:07.573
and so we're trying to go through what the hell is memory integrity enforcement.
00:01:08.188 --> 00:01:13.409
And how is it different than all this other stuff that's been deployed in say, Android or arm?
00:01:14.126 --> 00:01:15.266
so that's what we're trying to do.
00:01:15.933 --> 00:01:17.612
And just know Apple people.
00:01:17.673 --> 00:01:18.783
We know you're listening.
00:01:18.783 --> 00:01:20.313
We know you know who you are.
00:01:20.373 --> 00:01:23.403
We know that you know that we know who you are.
00:01:23.643 --> 00:01:27.423
And when we say things that are slightly inaccurate, you could have fixed this.
00:01:27.472 --> 00:01:27.822
Uhhuh.
00:01:29.335 --> 00:01:29.876
Okay.
00:01:29.936 --> 00:01:42.400
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.
00:01:42.921 --> 00:01:43.210
Okay.
00:01:43.570 --> 00:01:54.400
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.
00:01:55.018 --> 00:01:57.927
Very good, very good OPSEC or something.
00:01:58.635 --> 00:02:05.302
okay, so this is this whole memory integrity enforcement is like a suite of things.
00:02:05.412 --> 00:02:15.378
basically it seems to be a bunch of improvements that they've already shipped to their kernel allocators and to their user land allocators.
00:02:15.979 --> 00:02:21.498
But also how they're actually managing memory much farther down in the stack.
00:02:21.979 --> 00:02:29.338
And some of these are becoming available to previous ioss and Mac oss and I assume, you know, vision OSS or whatever.
00:02:29.709 --> 00:02:44.709
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.
00:02:45.218 --> 00:03:00.308
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.
00:03:00.633 --> 00:03:02.463
but also are difficult.
00:03:02.864 --> 00:03:07.033
a lot of times on our podcast we've talked about, you know, write your code in a memory safe language.
00:03:07.633 --> 00:03:12.163
And a lot of these vulnerabilities are addressed by writing code in a memory safe language.
00:03:12.644 --> 00:03:20.324
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.
00:03:20.604 --> 00:03:33.600
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.
00:03:33.811 --> 00:03:36.705
But also there are things that you do and you are.
00:03:37.372 --> 00:03:47.342
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.
00:03:47.342 --> 00:03:51.693
And you can't just, you have to be doing weird things with memory and stuff like that.
00:03:51.693 --> 00:03:53.823
So you can't just rewrite the world in rust.
00:03:54.272 --> 00:04:00.652
this is a lot of stuff that's trying to address that sort of, security posture, like deep, deep, deep in the stack.
00:04:01.032 --> 00:04:09.193
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.
00:04:09.223 --> 00:04:09.462
Okay.
00:04:09.462 --> 00:04:14.439
So, we're just basically gonna plow through this post and just branch out from there.
00:04:15.106 --> 00:04:19.697
iOS attacks, mercenary software, blah, blah, blah.
00:04:19.757 --> 00:04:20.146
Yes.
00:04:20.146 --> 00:04:21.226
Very important.
00:04:21.416 --> 00:04:26.613
And common denominator targeting using US iOS, windows and Android.
00:04:26.613 --> 00:04:32.374
They exploit memory safety vulnerabilities, which are interchangeable, powerful, and exist throughout the industry.
00:04:32.524 --> 00:04:34.579
I think the interchangeable thing is actually a really big deal.
00:04:35.122 --> 00:04:38.992
it's like a thing I think I like, it's a thing I think people are probably not gonna talk about enough.
00:04:39.172 --> 00:04:58.987
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.
00:04:58.987 --> 00:05:04.716
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.
00:05:04.716 --> 00:05:05.076
Right?
00:05:05.346 --> 00:05:25.526
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?
00:05:25.557 --> 00:05:28.346
It is weird to call them components, or maybe they are components, I don't know.
00:05:28.346 --> 00:05:33.826
But there's techniques that people use to pivot from, one kind of exploit primitive to the next exploit primitive.
00:05:33.887 --> 00:05:39.617
And I think a lot of modern exploit development depends on kind of plugging and playing techniques, right?
00:05:39.677 --> 00:05:47.807
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?
00:05:48.107 --> 00:06:01.247
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?
00:06:01.307 --> 00:06:06.297
So the path from the primitive to actually doing something useful, has to be built uniquely for every one of these things.
00:06:06.596 --> 00:06:07.797
Yeah, that makes sense.
00:06:08.117 --> 00:06:08.776
It also maybe.
00:06:09.201 --> 00:06:22.312
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.
00:06:22.312 --> 00:06:44.488
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.
00:06:44.999 --> 00:06:45.329
Okay.
00:06:45.838 --> 00:06:46.408
That makes sense.
00:06:47.115 --> 00:06:51.593
I wasn't sure what's the specifics were about interchangeable, but Yeah.
00:06:51.653 --> 00:06:52.163
That makes sense.
00:06:52.879 --> 00:06:55.879
Apple, improving memory, safety, swift, blah, blah, blah.
00:06:56.547 --> 00:07:07.617
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.
00:07:07.617 --> 00:07:11.937
Take advantage of knowing the type or purpose of allocation so that memory can be organized with it.
00:07:11.937 --> 00:07:15.627
It makes exploiting most memory corruption vulnerabilities inherently difficult.
00:07:15.956 --> 00:07:20.247
So I think this is the stuff that's like getting back ported to earlier devices.
00:07:20.276 --> 00:07:43.439
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.
00:07:44.168 --> 00:07:44.709
that's cool.
00:07:44.783 --> 00:07:46.134
and then only like.
00:07:46.800 --> 00:07:54.685
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.
00:07:55.225 --> 00:08:01.185
So that like, you can't ever say, like have a object that has like an integer in the first eight bytes.
00:08:01.185 --> 00:08:08.326
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.
00:08:08.795 --> 00:08:22.153
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.
00:08:22.187 --> 00:08:22.608
Mm-hmm.
00:08:22.992 --> 00:08:25.872
Thomas, can you explain what a use after free vulnerability is?
00:08:26.540 --> 00:08:29.894
You all know what a use after free vulnerability is Explain to our audience?
00:08:30.084 --> 00:08:34.274
Yeah, mean the name is pretty self-explanatory, but like why is it a vulnerability?
00:08:34.455 --> 00:08:37.154
I actually like didn't understand this until I worked on Chrome.
00:08:37.822 --> 00:08:42.822
I mean, I think the type confusion thing might be the simpl— like you just kind of laid out the obvious case, right?
00:08:42.822 --> 00:08:43.437
So like you.
00:08:44.104 --> 00:08:49.533
Especially in like complicated C and C++ code bases, like you're allocating memory and then explicitly freeing memory.
00:08:49.533 --> 00:08:52.114
And that happens in totally different places on the call chain.
00:08:52.114 --> 00:08:52.774
Sometimes.
00:08:52.984 --> 00:08:56.453
Like you might have something fire in response to a timer or something like that, right?
00:08:56.634 --> 00:08:59.663
So like this is a really pernicious class of bugs.
00:08:59.663 --> 00:09:01.014
Not even necessarily vulnerability.
00:09:01.014 --> 00:09:01.943
It's just bugs, right?
00:09:01.943 --> 00:09:06.083
Like you freed something when you didn't expect to free something and you held onto a pointer for it.
00:09:06.384 --> 00:09:09.519
If you induce those bugs deliberately, you wind up with.
00:09:10.129 --> 00:09:16.519
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.
00:09:16.519 --> 00:09:18.168
That's what you want to have happen, right?
00:09:18.198 --> 00:09:24.769
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.
00:09:24.769 --> 00:09:29.719
And like really strategically with the allocation pattern picked what your dangling pointer will now point to.
00:09:29.958 --> 00:09:39.298
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?
00:09:39.629 --> 00:09:44.849
And like the code path that's holding that dangling pointer somehow responds to user input.
00:09:45.058 --> 00:09:51.298
You write to the integer, and by writing to that integer, you're writing a pointer instead of, you know, just the integer.
00:09:51.418 --> 00:09:57.448
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.
00:09:57.688 --> 00:10:00.418
Like the code is confused about what the type it is, right?
00:10:00.719 --> 00:10:05.938
And you are now rewriting a pointer out from underneath the code and you can have it write to a location of your choosing.
00:10:06.605 --> 00:10:18.426
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.
00:10:18.426 --> 00:10:22.025
Like, execute this piece of code when you weren't supposed to.
00:10:22.625 --> 00:10:28.461
And then you can, leverage that however you like it's a way of getting a write-what-where primitive, right?
00:10:28.671 --> 00:10:34.160
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.
00:10:34.591 --> 00:10:38.941
and that usually historically is game over and making that not be game over.
00:10:39.607 --> 00:10:44.707
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.
00:10:44.967 --> 00:10:48.845
kind of one of the big things about MIE is making that not be game over anymore.
00:10:49.511 --> 00:10:50.081
Oh yeah.
00:10:50.111 --> 00:10:52.001
Making it not be game over.
00:10:52.062 --> 00:10:54.522
It's game over for the attacker.
00:10:54.942 --> 00:10:55.902
Ha ha ha.
00:10:56.568 --> 00:10:57.078
cool.
00:10:57.745 --> 00:10:58.645
So.
00:10:59.312 --> 00:10:59.673
Kay.
00:10:59.673 --> 00:11:05.163
Alec did its nice little thing inside the, the kernel.
00:11:05.732 --> 00:11:10.082
And then we have exon maek that's used by, you know, user land code.
00:11:10.633 --> 00:11:25.177
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.
00:11:25.177 --> 00:11:25.508
Right?
00:11:26.057 --> 00:11:27.677
or maybe you want to change something out.
00:11:28.102 --> 00:11:31.972
For something else because it's the kernel and you're fundamentally doing unsafe things.
00:11:32.312 --> 00:11:39.393
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.
00:11:39.722 --> 00:11:43.952
But in the kernel, like that's just kind of the way the world is sometimes.
00:11:43.952 --> 00:11:48.243
So just 'cause you have the allocator actually using it can be fairly complicated.
00:11:48.243 --> 00:11:54.370
Which Apple talks a lot about, in their massive Kal post from a couple years ago.
00:11:55.037 --> 00:11:59.537
Which, I'm just, I keep scrolling through because this is like the first time I'm looking at it.
00:11:59.537 --> 00:12:11.384
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?
00:12:11.563 --> 00:12:14.663
Like not a super common, building program primitive, right?
00:12:14.693 --> 00:12:20.394
So you have like, um, you have protections on like a page-based level based mostly on allocation sizes, right?
00:12:20.604 --> 00:12:35.094
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.
00:12:35.094 --> 00:12:36.474
Don't overshare the same memory.
00:12:36.524 --> 00:12:40.783
And then like, doing that at the level of a type thing, which requires compiler help.
00:12:41.183 --> 00:12:41.604
Mm-hmm.
00:12:42.129 --> 00:12:42.548
Mm-hmm.
00:12:42.854 --> 00:12:43.333
compiler help.
00:12:43.783 --> 00:12:44.083
Yeah.
00:12:44.083 --> 00:12:45.583
That's, that's, that's newish.
00:12:46.250 --> 00:12:46.730
Yeah.
00:12:46.760 --> 00:12:55.378
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.
00:12:55.701 --> 00:13:00.201
there is a recent actual, CL and like c plus plus extension.
00:13:00.662 --> 00:13:07.062
typed operator knew that, I believe, I don't remember if LLVM like directly or if Apple or Google added it.
00:13:07.361 --> 00:13:25.782
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.
00:13:25.782 --> 00:13:31.152
And it just like, it's like, hey, you know, here's a random type information.
00:13:31.152 --> 00:13:32.501
Don't ask questions about it.
00:13:32.501 --> 00:13:32.741
Right?
00:13:32.772 --> 00:13:47.009
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.
00:13:47.119 --> 00:13:47.749
That's nice.
00:13:48.416 --> 00:13:49.255
I didn't know any of this.
00:13:49.972 --> 00:13:50.423
okay.
00:13:51.090 --> 00:13:58.559
I think that's like the first chunk of memory integrity enforcement, which is like stuff they already shipped basically.
00:13:58.649 --> 00:14:07.490
And it's the user land updates to ExOne Malick or introduction of ex Exxon Malick and the kernel land, chaotic type.
00:14:07.889 --> 00:14:10.830
keep in mind the total number of buckets here is limited.
00:14:10.879 --> 00:14:17.360
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.
00:14:17.360 --> 00:14:22.200
But there's an arbitrarily large number, at least in user land of types that you can encounter.
00:14:22.200 --> 00:14:24.570
And like at some point you have to start reusing buckets.
00:14:24.649 --> 00:14:35.673
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.
00:14:36.274 --> 00:14:39.910
This was very successful, with PAC behind us.
00:14:40.577 --> 00:14:47.378
PAC is like a goofy thing because like, well, I mean, it's not like I know nothing about P PAC.
00:14:47.638 --> 00:14:59.518
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.
00:14:59.518 --> 00:15:00.898
I never remember which one is which.
00:15:01.057 --> 00:15:10.197
and like basically it boils down to like, you replace like the function header, and assembly with like a pack where, jump and return.
00:15:10.865 --> 00:15:12.904
and you're supposed to get CFI out of it.
00:15:12.965 --> 00:15:19.654
And then there's like broader, but the like base concept behind pointer off is just somehow that like there is a signature.
00:15:20.059 --> 00:15:23.090
In the semi cryptographic sense in every pointer.
00:15:23.090 --> 00:15:26.299
And like that signature needs to be valid for the pointer to be valid.
00:15:26.299 --> 00:15:34.317
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.
00:15:34.876 --> 00:15:51.884
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.
00:15:51.884 --> 00:15:56.533
it helps, but like at the end of the day, like you can usually find a way around it.
00:15:57.058 --> 00:15:57.359
Okay.
00:15:57.658 --> 00:16:02.046
Brandon Aza had a talk about this in like 2020 blackout CET or pac.
00:16:02.712 --> 00:16:03.337
of PAC Bypasses.
00:16:03.852 --> 00:16:04.123
Okay.
00:16:05.090 --> 00:16:07.220
So that brings us to.
00:16:07.654 --> 00:16:15.575
MTE itself, or memory tagging extension, which is an arm specification that is technically in more things than just Apple devices.
00:16:15.991 --> 00:16:17.611
Memory, tagging, extension.
00:16:17.611 --> 00:16:19.711
MTE is from arm.
00:16:19.711 --> 00:16:21.001
It's independent of Apple.
00:16:21.668 --> 00:16:24.609
It's just a thing anyone can use for arm chips.
00:16:25.458 --> 00:16:29.749
I believe it's mandatory to implement in ARM 11 or ARM 10 or something like that.
00:16:29.778 --> 00:16:34.533
But like, nice, or it's not mandatory to implement, you know, it's a sign, not a cop, right?
00:16:34.533 --> 00:16:34.624
Like.
00:16:35.041 --> 00:16:36.160
I can't make you do anything.
00:16:36.827 --> 00:16:40.697
Um, yeah, memory tagging and tag checking system.
00:16:41.357 --> 00:16:43.817
Every memory allocation is tagged with a secret.
00:16:44.227 --> 00:16:48.357
this is sort of similar to the PAC signatures, except in the cryptographic sense.
00:16:48.357 --> 00:16:51.207
They're probably closer to MACs or whatever.
00:16:51.732 --> 00:16:52.092
Well, hold on.
00:16:52.092 --> 00:16:53.337
Like MTEM.
00:16:53.383 --> 00:16:53.832
MTE.
00:16:54.163 --> 00:16:54.342
Yeah.
00:16:54.342 --> 00:16:55.452
MTE tags are tiny.
00:16:55.618 --> 00:16:57.807
Yeah, MTE tag is just a four bit number.
00:16:57.807 --> 00:17:03.778
So you've got your 64 bit pointer and then somewhere else there is a four bit number associated with that pointer.
00:17:03.988 --> 00:17:04.522
That's your tag.
00:17:05.002 --> 00:17:05.292
okay.
00:17:05.323 --> 00:17:08.173
pack, pack signatures are larger, I thought.
00:17:08.682 --> 00:17:09.192
Right.
00:17:09.282 --> 00:17:15.482
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?
00:17:15.482 --> 00:17:20.502
I just dunno anything about pack signatures, or whatever they're called.
00:17:21.170 --> 00:17:22.019
yeah, there's signatures.
00:17:22.384 --> 00:17:24.102
Okay, cool.
00:17:24.519 --> 00:17:31.628
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.
00:17:31.628 --> 00:17:31.749
Right?
00:17:31.749 --> 00:17:32.888
It's supposed to be transparent.
00:17:33.288 --> 00:17:42.770
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.
00:17:43.438 --> 00:17:44.123
that's neat.
00:17:44.789 --> 00:17:45.180
Okay.
00:17:45.299 --> 00:17:51.057
So unlike that, MTE has four bits, that they have to be kept secret.
00:17:52.023 --> 00:17:56.703
But they are kept secret in the sense that they're like not in the pointer, right?
00:17:56.703 --> 00:17:58.114
They are somewhere else.
00:17:58.780 --> 00:18:11.516
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.
00:18:11.665 --> 00:18:13.915
Like graph coloring than like signing things.
00:18:13.915 --> 00:18:14.276
Right.
00:18:14.425 --> 00:18:19.385
What you care about is a diversity of different tags, within the locality of a piece of memory.
00:18:19.385 --> 00:18:20.855
Like if you, you know, right.
00:18:20.976 --> 00:18:23.016
You know, right off the end of one thing to the next thing.
00:18:23.016 --> 00:18:26.405
You need the tags to be different and you need to not leak the tags.
00:18:26.405 --> 00:18:33.050
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.
00:18:33.050 --> 00:18:39.471
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.
00:18:39.621 --> 00:18:49.708
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.
00:18:50.375 --> 00:18:52.865
it'll crash your program if it's in synchronous mode.
00:18:53.045 --> 00:18:57.724
And if it's in asynchronous mode, it'll keep running your program and then crash it later.
00:18:58.392 --> 00:19:00.229
Hmm, okay.
00:19:00.409 --> 00:19:00.588
yeah.
00:19:00.588 --> 00:19:04.726
It will continue execution until there's a context switch I mean, I guess interrupt.
00:19:05.175 --> 00:19:08.875
Yeah, I guess that's, part of the whole async thing, Yes.
00:19:09.296 --> 00:19:09.685
Okay.
00:19:10.353 --> 00:19:11.762
much more performant.
00:19:11.792 --> 00:19:17.492
'cause you can delay the check till later and like keep executing the code and probably do the checks less.
00:19:17.492 --> 00:19:22.202
'cause like imagine you abuse the same pointer like eight times in a row to do something.
00:19:22.202 --> 00:19:24.752
Like you really only need to like check it the first time.
00:19:25.053 --> 00:19:25.712
Oh, okay.
00:19:26.380 --> 00:19:33.787
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.
00:19:34.453 --> 00:19:34.814
Okay.
00:19:34.973 --> 00:19:35.534
then you can B.
00:19:35.834 --> 00:19:42.284
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.
00:19:42.284 --> 00:19:43.423
It's in pixel phones.
00:19:43.913 --> 00:19:47.243
I think it's in like pixel starting in 10 or something like that.
00:19:47.544 --> 00:19:48.574
eight pixel eight.
00:19:48.624 --> 00:19:48.983
pixel eight.
00:19:49.651 --> 00:19:54.270
And so you can actually go into Android settings somewhere and enable this.
00:19:54.451 --> 00:19:57.111
and apps that are like aware of it can leverage it.
00:19:57.111 --> 00:20:03.020
So if you turn MTE on in a pixel phone, like Chrome will run itself in async MTE mode.
00:20:03.461 --> 00:20:08.411
and in fact, this will happen automatically if you're in like the Android advanced protection mode on your device.
00:20:08.490 --> 00:20:11.040
and your device supports MTE, it will get turned on.
00:20:11.040 --> 00:20:15.151
And like Chrome, for example, will start using MTE in Async mode.
00:20:15.817 --> 00:20:17.478
oh, this is a developer option.
00:20:17.738 --> 00:20:18.248
yeah.
00:20:18.248 --> 00:20:25.238
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.
00:20:25.238 --> 00:20:28.930
So, And then synchronous classically has been very expensive.
00:20:29.596 --> 00:20:29.836
yeah.
00:20:29.836 --> 00:20:34.096
And then synchronous has been like, like double digit percentage expenses.
00:20:34.763 --> 00:20:39.864
But like, so graphene, for instance, graphene does synchronous in the kernel and async out of the kernel.
00:20:40.193 --> 00:20:46.013
And then I'm guessing that the intuition there is you spend most of your time in usual land, not in the kernel.
00:20:46.314 --> 00:20:52.644
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.
00:20:52.913 --> 00:20:56.064
So you can be, and also there are much more fun vulnerabilities in the kernel.
00:20:56.273 --> 00:20:57.413
So there's a higher payoff.
00:20:57.888 --> 00:20:58.699
Yes.
00:20:58.798 --> 00:21:13.383
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.
00:21:13.383 --> 00:21:19.442
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.
00:21:20.109 --> 00:21:30.856
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.
00:21:30.856 --> 00:21:35.896
When, like, when you're not on the highest end devices, that can actually be much more impactful.
00:21:36.564 --> 00:21:37.733
I could definitely see that.
00:21:38.401 --> 00:21:38.611
Yeah.
00:21:38.611 --> 00:21:39.661
I just confirmed that.
00:21:39.665 --> 00:21:49.105
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.
00:21:49.135 --> 00:21:52.165
'cause I was like, I don't remember turning the saw on my phone.
00:21:52.165 --> 00:21:59.147
It's like, no, you did, but by can enable it on an individual device without enabling it on your your account.
00:21:59.278 --> 00:22:02.817
but if you enable it on your account and sign in, it will get enabled on that device.
00:22:03.327 --> 00:22:03.548
Yes.
00:22:03.738 --> 00:22:04.028
Yeah.
00:22:04.153 --> 00:22:05.053
That's how it happened.
00:22:05.720 --> 00:22:06.140
Cool.
00:22:06.170 --> 00:22:16.835
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?
00:22:16.835 --> 00:22:22.214
There was like a spec for this, but it really didn't exist in hardware, for a while.
00:22:22.214 --> 00:22:27.045
It's never been in server software like Google jammed it into Pixel.
00:22:27.045 --> 00:22:31.345
We learned that, you know, apple put it into, some of their devices.
00:22:31.734 --> 00:22:34.585
but like it is not cheap.
00:22:34.585 --> 00:22:38.700
It is like a large percentage of the die area to put Oh.
00:22:39.025 --> 00:22:41.605
into a chip and it is not fast.
00:22:41.605 --> 00:22:49.525
Like there are other, there are other like things in this vein, like CHERI for example, that take like much less dye area.
00:22:49.734 --> 00:22:52.474
It's like a very small number of gates to add, CHERI.
00:22:52.795 --> 00:22:58.734
But, uh, you have to like do a code rewrite where you like, are like, all my pointers are 128 bits.
00:22:58.734 --> 00:22:59.875
Now let's see what happens.
00:22:59.904 --> 00:23:03.015
Um, for CHERI's also a bear performance hit, right?
00:23:03.382 --> 00:23:04.612
I'm not sure actually.
00:23:04.612 --> 00:23:06.082
I think it's smaller actually.
00:23:06.082 --> 00:23:09.082
It's just like you to make, use it effectively.
00:23:09.082 --> 00:23:11.721
You have to kind of define pointer domains and coach yourself.
00:23:11.721 --> 00:23:14.271
And at some point it's just like, dude, just rewrite it and rust.
00:23:14.602 --> 00:23:22.146
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.
00:23:22.176 --> 00:23:24.067
It's not just about the memory safety stuff.
00:23:24.096 --> 00:23:29.196
I didn't think so, but I'm not sure I can feel Ben, Lori getting upset listening to this.
00:23:29.547 --> 00:23:46.076
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.
00:23:46.416 --> 00:23:49.473
so, anyway, M ds cord memory tagging.
00:23:49.473 --> 00:23:50.223
Check sec Chad.
00:23:50.891 --> 00:23:53.560
Memory tagging and tag checking system.
00:23:53.661 --> 00:23:54.980
this got deployed on Pixel.
00:23:54.980 --> 00:23:58.191
It's been available in some places, but there's costs.
00:23:58.500 --> 00:24:04.221
Apple conducted a deep evaluation and research process to determine whether MTV is designed would meet our goals Okay.
00:24:04.246 --> 00:24:05.506
We don't need to read.
00:24:05.536 --> 00:24:09.171
We don't need to read these parts of the Well, I'm getting back into it.
00:24:09.171 --> 00:24:35.576
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.
00:24:35.935 --> 00:24:42.625
apple doesn't really say what EMTE does beyond like, it's just MTE in synchronous mode and fast, Hold on.
00:24:42.685 --> 00:24:46.895
So my understanding is that EMTE is just another name for MTE four.
00:24:47.346 --> 00:24:47.796
Right?
00:24:47.915 --> 00:24:50.945
Which is a set of like four MTE extensions.
00:24:51.613 --> 00:24:53.083
It's canonical pack checking.
00:24:53.083 --> 00:24:55.363
It's the one they list in the blog post.
00:24:55.643 --> 00:25:03.323
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?
00:25:03.323 --> 00:25:06.472
Like you have variables that are not in tagged regions, right?
00:25:06.682 --> 00:25:09.532
And in standard MTE, those aren't, there's no checking for that.
00:25:09.923 --> 00:25:23.109
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.
00:25:23.777 --> 00:25:26.207
So like, in theory, it should automatically detect, right?
00:25:26.257 --> 00:25:32.797
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.
00:25:33.307 --> 00:25:36.217
And I guess that wasn't chucked before and now it is with MTE four.
00:25:36.741 --> 00:25:37.011
Hmm.
00:25:37.679 --> 00:25:51.949
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.
00:25:52.068 --> 00:26:03.009
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.
00:26:03.038 --> 00:26:11.375
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.
00:26:11.375 --> 00:26:12.096
I don't, I don't know.
00:26:12.762 --> 00:26:29.998
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.
00:26:30.508 --> 00:26:34.258
we're coming up on my favorite section of this post, or my favorite sentence in the post.
00:26:34.438 --> 00:26:38.367
Just like consider that you could do either AY or synchronous mode.
00:26:38.667 --> 00:26:43.498
Synchronous is the good mode and asynchronous is the bad mode We could have implemented asynchronous.
00:26:43.948 --> 00:26:45.837
We would not implement such a mechanism.
00:26:46.505 --> 00:26:49.211
Apple, please run these things by me.
00:26:49.878 --> 00:27:05.215
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?
00:27:05.215 --> 00:27:09.536
They've presumably been experimenting with this and just like not turning it on.
00:27:09.536 --> 00:27:21.925
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.
00:27:21.996 --> 00:27:22.115
it.
00:27:22.286 --> 00:27:24.056
all they had to do was use a different verb there.
00:27:24.056 --> 00:27:30.030
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.
00:27:30.086 --> 00:27:30.546
So weird.
00:27:31.313 --> 00:27:41.113
Um, what you mean by implement, which in this very, uh, very massage, public facing texts might mean implement and deploy and ship.
00:27:41.480 --> 00:27:51.740
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.
00:27:51.890 --> 00:27:53.329
'cause look, you, you hear us?
00:27:53.329 --> 00:27:54.230
We don't know what we're talking.
00:27:54.319 --> 00:27:57.109
David knows a little bit about what he's talking about, but I don't Right.
00:27:57.109 --> 00:27:58.130
We could use the help.
00:27:58.309 --> 00:28:02.539
I wanna call out though that the graphene project, there's an angry thread that, responded to this thing.
00:28:02.779 --> 00:28:04.970
I won't read that whole thread, but it's worth reading.
00:28:05.210 --> 00:28:10.849
And they say that there's basically no difference that they've seen in terms of breaking exploits by having ay versus synchronous.
00:28:11.089 --> 00:28:12.589
Like to them ayc is enough.
00:28:12.957 --> 00:28:13.247
Okay.
00:28:13.913 --> 00:28:16.044
Depends on how much you care about what graphene thinks.
00:28:16.134 --> 00:28:23.739
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.
00:28:24.499 --> 00:28:24.659
Interesting.
00:28:24.669 --> 00:28:25.209
is what it is.
00:28:25.875 --> 00:28:29.476
the thing about MTE generally and then particularly about async, right?
00:28:29.476 --> 00:28:33.955
Is that like you have, so you have four bits, of entropy with the pointer.
00:28:34.226 --> 00:28:42.066
And in some cases, like let's say you're a web browser that runs like arbitrary JavaScript, depending on what the behavior is.
00:28:42.096 --> 00:29:03.200
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.
00:29:03.866 --> 00:29:09.297
like if you're able to just do it in the background and like no one's really the wiser somehow by like.
00:29:09.963 --> 00:29:14.284
Having some JavaScripts that then like loads another page that tries it 16 times.
00:29:14.284 --> 00:29:19.060
So that, like that process that you never see is the one that dies because it's whatever.
00:29:19.121 --> 00:29:25.825
Then, um, then suddenly like, you know, MTE is not like this be all, end all.
00:29:25.894 --> 00:29:35.555
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.
00:29:35.704 --> 00:29:46.684
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.
00:29:46.984 --> 00:29:47.404
Mm-hmm.
00:29:47.755 --> 00:29:51.464
but that's all gonna depend on like, you know, what your program mm-hmm.
00:29:51.765 --> 00:30:04.321
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.
00:30:04.457 --> 00:30:04.622
yeah.
00:30:05.394 --> 00:30:08.138
Oh, poor web browsers And it can all change dynamically.
00:30:08.806 --> 00:30:12.496
You don't even get a canonical version of the code to download before you run it.
00:30:12.796 --> 00:30:15.496
downloaded that webpage two minutes ago.
00:30:15.526 --> 00:30:15.976
Fuck you.
00:30:16.643 --> 00:30:18.383
You don't get to rely on that at all.
00:30:19.049 --> 00:30:20.069
Apple says.
00:30:20.595 --> 00:30:25.154
That always on synchronous MTE across key attack surfaces.
00:30:25.394 --> 00:30:40.275
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.
00:30:40.991 --> 00:30:45.672
MT for M-T-V-M-T-E to provide memory safety in an adversarial context.
00:30:45.672 --> 00:30:55.402
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.
00:30:56.068 --> 00:31:04.296
We would carry out a massive engineering effort spending all of, All of Apple, apple silicon operating systems are software frameworks.
00:31:04.296 --> 00:31:05.135
Excuse me.
00:31:05.135 --> 00:31:09.546
I think there's some computers in Apple that run in the cloud, the Apple cloud.
00:31:09.550 --> 00:31:15.762
That, that they were not listed in that list there, so citation needed, okay.
00:31:16.212 --> 00:31:26.262
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.
00:31:26.373 --> 00:31:45.920
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.
00:31:46.505 --> 00:31:50.075
We haven't talked about that at all, and I don't think, I think that's down at the bottom.
00:31:50.075 --> 00:31:51.761
We have to get to that.
00:31:52.479 --> 00:31:57.429
and it's built into Apple hardware and software and all models of iPhone 17, iPhone air.
00:31:57.798 --> 00:32:04.148
and I think they said in their announcement that it's gonna come to either the next MacBook or the latest MacBook.
00:32:04.148 --> 00:32:05.019
I forget which one.
00:32:05.528 --> 00:32:06.638
soon.
00:32:07.306 --> 00:32:07.816
Cool.
00:32:08.482 --> 00:32:14.069
And it seems like the real win here is doing all of these things together.
00:32:14.737 --> 00:32:29.217
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.
00:32:29.217 --> 00:32:30.116
Synchronously always.
00:32:30.747 --> 00:32:34.176
And not crawl the os to a halt.
00:32:34.237 --> 00:32:37.896
They were able to make all these improvements, to do all this stuff all the time.
00:32:38.326 --> 00:32:42.376
and it's still a performant iPhone and it's not, you know, killing your battery, basically.
00:32:42.886 --> 00:32:48.084
and that's a thing that Apple is in a unique position to do, to do well.
00:32:48.451 --> 00:32:52.260
I think that like, that's the, actually the big takeaway is that they're doing it fast.
00:32:52.260 --> 00:32:56.010
Like all of this stuff has existed for a while and is like good.
00:32:56.250 --> 00:33:01.351
It's, it's effective, but it's not like a hundred percent effective and it's been in stuff for a while.
00:33:01.351 --> 00:33:03.480
Like not just, just Apple, right?
00:33:03.480 --> 00:33:20.240
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.
00:33:20.907 --> 00:33:22.178
that only works for heap pointers.
00:33:22.198 --> 00:33:27.178
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.
00:33:27.478 --> 00:33:27.877
Mm-hmm.
00:33:28.178 --> 00:33:29.647
you have that stuff in other places.
00:33:29.647 --> 00:33:32.917
You have had asynchronous MTE on other devices.
00:33:33.278 --> 00:33:41.407
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.
00:33:41.708 --> 00:33:42.127
Mm-hmm.
00:33:42.478 --> 00:33:46.107
Alec is on in like most of Chrome, but it's not on like everywhere.
00:33:46.107 --> 00:33:47.577
Everywhere, for example.
00:33:47.877 --> 00:33:48.087
Okay.
00:33:48.755 --> 00:33:48.974
Yep.
00:33:49.692 --> 00:33:52.278
so they're reviewing the memory allocators.
00:33:52.945 --> 00:33:56.066
Are you familiar with Lib Pass Web kit's, web Pass?
00:33:56.482 --> 00:34:01.222
I believe it's just their way of basically doing like per object heaps at like the type level.
00:34:01.432 --> 00:34:08.309
Um, but yeah, it's just like a c plus plus e version of, of doing the like type based allocations.
00:34:08.677 --> 00:34:12.126
all use type information to decide how to organize memory allocations.
00:34:12.527 --> 00:34:20.112
so if those are all c which is not strongly typed, Lib has a c plus plus Okay.
00:34:20.112 --> 00:34:20.442
All right.
00:34:21.108 --> 00:34:33.559
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.
00:34:33.739 --> 00:34:40.009
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.
00:34:40.009 --> 00:34:40.789
Bugs overlap.
00:34:40.878 --> 00:34:41.418
Yeah, go ahead.
00:34:41.719 --> 00:35:00.806
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.
00:35:01.472 --> 00:35:09.003
and basically at the compiler level ensuring that like that size parameter is in fact enforced and that like there are checks.
00:35:09.583 --> 00:35:27.875
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.
00:35:28.195 --> 00:35:33.934
and then also like corresponding, compiler passes if you don't want to enforce that just for detecting, um, when it happens.
00:35:33.934 --> 00:35:45.155
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.
00:35:45.155 --> 00:35:51.244
You can be like, no more raw pointer accesses in this directory, aside from the existing ones.
00:35:51.505 --> 00:35:51.744
nice.
00:35:51.744 --> 00:36:00.954
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.
00:36:01.614 --> 00:36:02.155
Cool.
00:36:02.822 --> 00:36:10.172
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.
00:36:10.472 --> 00:36:12.481
and to their credit, they were driving a lot of it too, right?
00:36:12.481 --> 00:36:14.581
Like they have a lot of clang developers Yeah.
00:36:14.791 --> 00:36:22.206
Well, I'm not surprised, and they used to have, what's his name, who like created LLVM, Chris Latner.
00:36:22.690 --> 00:36:22.981
Cool.
00:36:23.648 --> 00:36:23.768
Yeah.
00:36:24.068 --> 00:36:25.987
That's a, that makes a lot of sense.
00:36:26.655 --> 00:36:27.255
okay.
00:36:27.795 --> 00:36:33.534
Tpo wear placement policies over secure memory allocators helped work memory corruption, Okay.
00:36:33.534 --> 00:36:34.164
Yes.
00:36:34.224 --> 00:36:36.474
Does not, does hit performance.
00:36:36.574 --> 00:36:39.364
performance is either even as the same or better.
00:36:40.025 --> 00:36:45.784
Allocators can apply protections only at the granularity of memory pages 16 kilobytes on iOS.
00:36:46.215 --> 00:36:53.835
for smaller allocations, secure allocators can use page level protections to help prevent memory corruption attacks across different type buckets.
00:36:53.835 --> 00:36:58.605
However, page level protections are to coarse defending as attacks within the same type bucket.
00:36:58.695 --> 00:37:00.554
And we use memory tagging to close this gap.
00:37:00.585 --> 00:37:06.981
So it's not just like, cool, we do stuff at the allocators and then we do memory tagging, you know, as well.
00:37:06.981 --> 00:37:09.641
It's like, no, no, no, we have to cover.
00:37:10.152 --> 00:37:12.822
The page level and cross page stuff.
00:37:12.882 --> 00:37:26.376
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.
00:37:26.677 --> 00:37:27.007
Cool.
00:37:27.157 --> 00:37:27.487
All right.
00:37:28.117 --> 00:37:33.097
And that's where the EMT is comes in to be And to be fair, that's like most objects.
00:37:33.764 --> 00:37:33.943
Okay.
00:37:34.204 --> 00:37:37.503
most objects are smaller than the full 16 kilobyte page.
00:37:37.864 --> 00:37:40.143
Not out, out here allocating pages.
00:37:40.760 --> 00:37:48.701
Um, EMT protects against two of the most common types of memory corruption, buffer overflows in use after free, which we talked about.
00:37:49.130 --> 00:37:54.440
But for overflows, allocator is responsible for using different tags for name allocations.
00:37:54.871 --> 00:38:02.976
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.
00:38:03.275 --> 00:38:03.565
Yeah.
00:38:03.570 --> 00:38:03.780
Yeah.
00:38:03.780 --> 00:38:05.311
This is the easiest one to get your head around.
00:38:05.356 --> 00:38:14.400
where they diagram it and we covered it earlier, they have a nice diagram with emoji and colors to show how MTE works.
00:38:14.400 --> 00:38:17.251
It's not very complicated to understand the core concept.
00:38:17.617 --> 00:38:19.927
We will save you from explaining the diagrams.
00:38:20.588 --> 00:38:28.208
Um, uh, wait, that's, yeah, that's the buffer overflow where you're just going over the type over the area.
00:38:28.208 --> 00:38:32.228
And this is the one where you're, using after free.
00:38:32.257 --> 00:38:45.007
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.
00:38:45.675 --> 00:38:46.065
Nice.
00:38:46.215 --> 00:38:46.574
or less.
00:38:46.574 --> 00:38:46.905
Yeah.
00:38:47.572 --> 00:38:52.842
I would also just say in modern, projects, there can be spatial memory safety errors, like when.
00:38:53.427 --> 00:38:54.987
First learn about memory on safety.
00:38:54.987 --> 00:39:20.447
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.
00:39:20.447 --> 00:39:21.766
Like, is, is fairly common.
00:39:22.081 --> 00:39:24.617
And, and like enforcing everybody uses that.
00:39:24.617 --> 00:39:32.297
Like, you get pretty close to very high coverage of like your, your spatial memory safety, at least when it comes to containers.
00:39:32.746 --> 00:39:36.632
Um, not necessarily like a crap on the stack or mm-hmm.
00:39:36.697 --> 00:39:37.922
lifecycle is a nightmare.
00:39:38.237 --> 00:39:40.036
yeah, lifecycle is a nightmare.
00:39:40.097 --> 00:39:48.016
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.
00:39:48.684 --> 00:39:52.014
It's the ones where it's like, okay, we've handled all of those.
00:39:52.014 --> 00:40:04.173
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.
00:40:04.173 --> 00:40:17.014
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.
00:40:17.373 --> 00:40:21.733
But a lifecycle vulnerability could span, 15 different functions called the different times.
00:40:21.804 --> 00:40:22.094
Yeah.
00:40:22.324 --> 00:40:22.614
Okay.
00:40:22.981 --> 00:40:28.621
you can enable like hardened lib c plus plus, I think with a pound f or maybe a compiler flag or both.
00:40:29.010 --> 00:40:35.047
Um, that just like puts checks everywhere in, in like the CC plus plus standard lib, for example.
00:40:35.378 --> 00:40:39.007
Um, 'cause like by default only some of the methods actually like do check access.
00:40:39.675 --> 00:40:42.485
it was less so that like we didn't know how to do this for years.
00:40:42.485 --> 00:40:46.414
It was just like, oh, well the performance impact of putting the checks everywhere is too high, so we can't do it.
00:40:46.414 --> 00:40:48.364
We'll assume the programmer put it in the right spot.
00:40:48.784 --> 00:40:57.304
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.
00:40:57.635 --> 00:41:04.025
Um, and then eventually, like some other people followed as well and like that got the compiler people looking at it.
00:41:04.204 --> 00:41:16.235
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.
00:41:16.324 --> 00:41:18.875
This happens a lot in like rust with Iterators and stuff.
00:41:18.875 --> 00:41:23.684
Like the vast majority of the checks end up getting optimized out by the compiler, because they're redundant.
00:41:24.065 --> 00:41:27.699
and so like once you actually put it, the effort into writing those optimizations.
00:41:28.367 --> 00:41:29.806
Then the harden mode gets faster.
00:41:29.806 --> 00:41:35.266
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.
00:41:35.266 --> 00:41:38.507
And then the compiler people were like, we're not optimizing that 'cause no one's using it.
00:41:38.567 --> 00:41:38.657
this.
00:41:38.657 --> 00:41:53.929
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.
00:41:54.596 --> 00:41:59.385
okay, we're, we're trying to zoom through this so we can wrap up before, we all have to disappear.
00:41:59.835 --> 00:42:05.385
weakness of original MTE access to non-tech memory, global variables not checked by hardware.
00:42:05.675 --> 00:42:06.846
this is nice for attackers.
00:42:07.146 --> 00:42:07.971
I don't get this.
00:42:08.630 --> 00:42:10.731
There's a thing I don't get about this, right.
00:42:10.820 --> 00:42:19.197
Which is like, so the, the mitigation here is that attackers have to know the tag of the region that they're coming from.
00:42:19.197 --> 00:42:23.217
Now to do this, we're talking about writing into untagged memory, right?
00:42:23.367 --> 00:42:25.168
So what is the actual pattern here?
00:42:25.228 --> 00:42:34.644
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.
00:42:34.644 --> 00:42:36.804
What does it mean to know the tag of the, of the tagged region?
00:42:37.472 --> 00:42:38.161
Do any of us know?
00:42:38.802 --> 00:42:58.179
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?
00:42:58.179 --> 00:43:03.548
Then that function pointer as a tag Because the function pointer is in the, whatever the non-data segment is called.
00:43:03.548 --> 00:43:04.179
I don't remember.
00:43:04.539 --> 00:43:07.148
It's like the centerpiece Of how they're describing EMTE.
00:43:07.518 --> 00:43:10.016
Well, I don't believe in reading assembly.
00:43:10.076 --> 00:43:16.568
So, so beyond global variables, they also talk about trying to mitigate, specter or, Oh right.
00:43:16.652 --> 00:43:27.581
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.
00:43:28.074 --> 00:43:31.269
this is and they say they mitigate this Yes.
00:43:31.269 --> 00:43:44.407
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.
00:43:44.407 --> 00:43:46.987
all we know about No, we know a lot.
00:43:47.286 --> 00:43:47.586
No.
00:43:47.617 --> 00:43:52.577
We know a lot about the secured page, stable monitor, there's a paper about it that kind of unwinds the whole thing.
00:43:52.577 --> 00:43:55.606
Works out what all the function calls Oh, this, this one.
00:43:55.907 --> 00:43:56.297
Yeah.
00:43:56.597 --> 00:43:58.036
We'll throw this in the notes.
00:43:58.197 --> 00:43:59.186
and great job.
00:43:59.186 --> 00:44:05.186
To the authors of this paper whose names I will slaughter, paper from, did I find that paper?
00:44:05.186 --> 00:44:07.467
Was that paper released like seven days ago?
00:44:08.134 --> 00:44:11.574
maybe, 10th of October, 2025, current revision.
00:44:12.083 --> 00:44:13.164
12 days ago.
00:44:13.463 --> 00:44:13.614
yeah.
00:44:13.643 --> 00:44:14.454
And that's V one.
00:44:14.753 --> 00:44:15.244
Hell yeah.
00:44:15.393 --> 00:44:22.356
so I guess they were, we were not the only people intrigued by, uh, intrigued by this blog post in reference.
00:44:23.023 --> 00:44:29.659
perhaps, although this looks like it's also a master's thesis, so maybe they were starting long before.
00:44:29.960 --> 00:44:35.719
the vibe is that you're running a big chunk of the virtual memory subsystem of the kernel in like an enclave.
00:44:36.385 --> 00:44:36.804
Mm-hmm.
00:44:36.829 --> 00:44:37.670
I guess so.
00:44:37.739 --> 00:44:44.460
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.
00:44:44.465 --> 00:44:44.885
Mm-hmm.
00:44:45.300 --> 00:44:47.909
Like you just, you've got control over memory in the kernel.
00:44:47.909 --> 00:44:51.900
You can bounce around, you can just flip things to be executable or not executable, whatever.
00:44:52.266 --> 00:44:59.347
whenever anyone mentions a trust zone, I just immediately think of it in to the tune of the song, white Room.
00:44:59.347 --> 00:45:04.507
In the White Room, but I wanna say cream, but In the trust zone.
00:45:04.927 --> 00:45:05.166
Exactly.
00:45:05.166 --> 00:45:06.876
With white curtains?
00:45:06.876 --> 00:45:07.806
No, it's the other way around.
00:45:08.347 --> 00:45:10.012
In the white room with black curtains.
00:45:10.311 --> 00:45:12.297
have nothing to do with any of what you guys are talking about.
00:45:12.963 --> 00:45:23.751
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.
00:45:24.295 --> 00:45:24.585
Yeah.
00:45:25.253 --> 00:45:25.762
Okay.
00:45:25.822 --> 00:45:27.293
So those are the three main pieces.
00:45:27.293 --> 00:45:32.152
Then we've got the improved type informed allocate, secure allocators.
00:45:32.432 --> 00:45:37.750
we've got the enhanced extended memory tagging, extension, whatever.
00:45:37.989 --> 00:45:50.869
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.
00:45:51.179 --> 00:45:52.510
and that's based, that's it.
00:45:52.539 --> 00:45:56.170
that's memory integrity enforcement or whatever.
00:45:56.650 --> 00:45:57.130
cool.
00:45:57.797 --> 00:45:58.427
Let's see.
00:45:58.516 --> 00:46:11.746
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.
00:46:12.146 --> 00:46:15.686
Evaluating pointer authentication instructions, speculatively.
00:46:15.806 --> 00:46:18.626
Yeah, that's, that's Specter V one, right?
00:46:18.987 --> 00:46:23.614
Yes, that's Vector V one, which was basically never fully mitigated.
00:46:23.704 --> 00:46:25.773
We just kind of were like, eh, it's probably fine.
00:46:26.344 --> 00:46:32.045
We'll split stuff at the like, like the kernel will deal with it if you care about it at a per process level.
00:46:32.266 --> 00:46:33.126
And if you know.
00:46:33.793 --> 00:46:37.543
You care about it within a process, well just split your stuff into multiple processes, right?
00:46:37.543 --> 00:46:38.112
Like that.
00:46:38.112 --> 00:46:43.152
That's what the usual mitigation is, is like figure out what your security boundary is and then, you know, cut it.
00:46:43.273 --> 00:46:43.333
it.
00:46:43.572 --> 00:46:43.963
Yep.
00:46:44.012 --> 00:46:46.713
is why like Chrome has site isolation.
00:46:47.072 --> 00:46:55.668
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.
00:46:55.668 --> 00:46:59.463
In the same process is to simply not put two sites in the same process.
00:46:59.523 --> 00:46:59.972
same process.
00:47:00.302 --> 00:47:00.782
Yep.
00:47:01.460 --> 00:47:05.420
And this is like, if you really care about Specter V one.
00:47:06.086 --> 00:47:15.146
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.
00:47:15.356 --> 00:47:22.646
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.
00:47:22.887 --> 00:47:23.487
Oh, sorry.
00:47:23.487 --> 00:47:24.853
Money, please.
00:47:26.581 --> 00:47:30.331
let's see if we can cover the rest of this real quick.
00:47:30.690 --> 00:47:31.831
Okay.
00:47:31.831 --> 00:47:32.456
Specter to cover.
00:47:33.123 --> 00:47:38.855
No solution to this problem, blah, blah, they addressed Specter with the secure page, table thing that we just discussed.
00:47:39.521 --> 00:47:43.001
And then they're protecting their users with memory integrity enforcement.
00:47:43.668 --> 00:47:50.929
Um, and that user does not involve me because of my aforementioned inability to input the correct address when ordering a phone.
00:47:52.856 --> 00:47:57.730
Protect all users by defaults and yeah.
00:47:57.730 --> 00:48:01.929
Google took a great first step last year when they offered MTE, those to opt in.
00:48:02.380 --> 00:48:08.574
Good for them, but technically into MTE without opting into the program for at-risk users.
00:48:08.574 --> 00:48:12.025
But yes, it's been on the phone for a number of years at this point.
00:48:12.309 --> 00:48:12.519
you.
00:48:12.519 --> 00:48:18.909
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.
00:48:18.909 --> 00:48:23.800
But you have to opt, you have to opt into it unless you are in the Advanced Protection Program.
00:48:24.219 --> 00:48:35.114
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.
00:48:35.474 --> 00:48:39.375
Which brings us to like the elephant in the room of X 64.
00:48:39.925 --> 00:48:43.045
so like X 64 right?
00:48:43.045 --> 00:48:51.085
Is like a MD and Intel and they have some sort of like intracompany board that like sets what the instruction set is, right?
00:48:51.085 --> 00:48:55.614
Because it was basically an instruction set written by AMD to look like Intel.
00:48:56.045 --> 00:49:04.204
they are still discussing what the instructions for MTE would even look like on X 64.
00:49:04.355 --> 00:49:15.525
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.
00:49:15.994 --> 00:49:21.275
so this is really like an ARM 64 thing and a subset of arm 64 thing.
00:49:21.844 --> 00:49:31.092
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.
00:49:31.496 --> 00:49:45.603
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?
00:49:45.603 --> 00:49:47.134
There's still edge cases with that.
00:49:47.134 --> 00:49:52.724
Like what happens in your program writes out other code into the process and, uh, is a JIT.
00:49:52.744 --> 00:49:56.164
And that has logic bugs where it writes out the wrong code, right?
00:49:56.164 --> 00:49:59.829
Like memory, safe languages don't help, rust, it doesn't help you there.
00:50:00.128 --> 00:50:00.548
Mm-hmm.
00:50:00.898 --> 00:50:08.728
hopefully you know that these are all things that can happen in parallel, um, and should all combine to build a better system.
00:50:09.224 --> 00:50:09.443
Yes.
00:50:09.753 --> 00:50:23.353
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.
00:50:24.019 --> 00:50:27.675
And even we'll see if they even do like emulation stuff still.
00:50:27.735 --> 00:50:31.394
'cause they still have the old stuff and they still have a bunch of apple silicon.
00:50:31.394 --> 00:50:36.315
So yeah, you, you won't even have that, even if you're Apple for a long, long, long, long time.
00:50:36.981 --> 00:50:40.911
and like we said, it is, there is a probabilistic element to all of this.
00:50:40.911 --> 00:50:43.541
It's not deterministic, and so Mm-hmm.
00:50:43.641 --> 00:50:50.782
it may be the case that we figure out ways to make that, one in 16 chance your exploit works to be much higher.
00:50:51.449 --> 00:50:56.900
Or the lower, the chance that it works, lower it works to be much higher, right?
00:50:56.900 --> 00:50:57.771
Like Oh.
00:50:57.826 --> 00:50:57.996
right.
00:50:58.036 --> 00:51:07.210
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.
00:51:07.510 --> 00:51:13.251
So basically the lowest chances for the attacker are right now because this yeah, one in, one in 16.
00:51:13.715 --> 00:51:14.016
yeah.
00:51:14.045 --> 00:51:15.036
They could only get better.
00:51:15.335 --> 00:51:15.606
Yeah.
00:51:15.786 --> 00:51:16.115
Okay.
00:51:16.782 --> 00:51:18.432
Use the secure allocators first.
00:51:18.432 --> 00:51:22.932
Use extended MTE to protect smaller individual allocations within the type bucket.
00:51:23.322 --> 00:51:31.273
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.
00:51:31.693 --> 00:51:44.382
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.
00:51:44.432 --> 00:51:50.132
our hardware implementation influence additional software design decisions, reducing overhead of tag extracts even further.
00:51:50.552 --> 00:52:05.543
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.
00:52:05.543 --> 00:52:13.702
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.
00:52:13.882 --> 00:52:18.333
And I don't know if it is slightly faster than the previous generation.
00:52:18.672 --> 00:52:30.086
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.
00:52:30.117 --> 00:52:30.626
Aware about.
00:52:30.657 --> 00:52:31.166
Okay.
00:52:31.347 --> 00:52:36.123
And then checking how secure it is.
00:52:36.318 --> 00:52:42.739
any developer can begin testing the protection including EMT on hardware that supports it using enhanced security settings next code.
00:52:42.768 --> 00:52:45.619
So if you're a dev, you still have to opt in.
00:52:46.286 --> 00:52:57.672
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.
00:52:58.003 --> 00:53:06.672
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.
00:53:07.043 --> 00:53:08.152
they have a big diagram here.
00:53:08.869 --> 00:53:20.637
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.
00:53:21.603 --> 00:53:38.445
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.
00:53:38.873 --> 00:53:46.193
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.
00:53:46.748 --> 00:53:49.027
Four or five of eight steps.
00:53:49.157 --> 00:53:52.547
but like, what does that, what does that really mean?
00:53:52.757 --> 00:54:10.409
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?
00:54:10.739 --> 00:54:22.550
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?
00:54:22.550 --> 00:54:35.554
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.
00:54:35.583 --> 00:54:37.304
It's pretty far right for the rest of 'em.
00:54:37.971 --> 00:54:47.271
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.
00:54:47.690 --> 00:54:53.001
Versus like something like EMTE is more likely to kind of like cut off the base concept.
00:54:53.668 --> 00:54:55.782
Um, but who knows?
00:54:56.081 --> 00:54:56.351
yeah.
00:54:57.012 --> 00:54:57.371
Cool.
00:54:57.492 --> 00:54:58.032
I like this.
00:54:58.032 --> 00:54:58.891
It's, informative.
00:54:58.922 --> 00:55:00.338
It's, yeah.
00:55:01.005 --> 00:55:01.576
Cool.
00:55:02.242 --> 00:55:02.842
Nice stuff.
00:55:02.842 --> 00:55:03.353
Apple.
00:55:04.054 --> 00:55:09.380
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.
00:55:09.380 --> 00:55:10.730
And I find it confusing.
00:55:11.059 --> 00:55:11.269
Yeah.
00:55:11.269 --> 00:55:13.070
And this post was by seer.
00:55:13.130 --> 00:55:15.199
I don't know what SPEAR stands for.
00:55:15.590 --> 00:55:19.034
Platform, software I don't know what either of 'em stand for.
00:55:19.164 --> 00:55:19.284
for.
00:55:19.353 --> 00:55:19.643
Yeah.
00:55:20.043 --> 00:55:23.403
SEER is, I know is people join them and then you never hear from them again.
00:55:23.764 --> 00:55:24.813
They disappear.
00:55:25.530 --> 00:55:28.010
SEAR, security, engineering and architecture.
00:55:28.215 --> 00:55:28.755
I assume.
00:55:28.755 --> 00:55:41.835
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.
00:55:42.056 --> 00:55:46.760
and it like gives them amnesia and they, how to interact with the rest of industry.
00:55:47.690 --> 00:55:53.655
Uhhuh Apple's doing its damnedest to be like, no, really, we're very, very secure.
00:55:54.074 --> 00:55:54.914
Uh, phone.
00:55:55.581 --> 00:56:00.148
You by our phones, so we'll see if anyone introduces, uh uh.
00:56:00.815 --> 00:56:06.695
Some sort of hardware fault isolation for securing things like JITs in the future, but That'd be nice.
00:56:07.603 --> 00:56:07.873
Cool.
00:56:07.902 --> 00:56:09.882
I have a whole blog post about that if you're interested.
00:56:10.498 --> 00:56:12.038
security, cryptography, whatever is a.
00:56:12.672 --> 00:56:13.302
Oh yeah.
00:56:13.969 --> 00:56:14.260
Cool.
00:56:14.599 --> 00:56:18.710
Security, Cryptography, Whatever is a side project from Deirdre Connolly, Thomas Ptacek and David Adrian.
00:56:18.710 --> 00:56:19.940
Our editor is Netty Smith.
00:56:19.969 --> 00:56:23.039
You can find the podcast online at scwpod.
00:56:23.420 --> 00:56:27.179
And the host online at durumcrustulum at tqbf, and at davidcadrian.
00:56:27.380 --> 00:56:30.960
You go by merch online at merch dot security cryptography whatever dot com.
00:56:30.980 --> 00:56:36.199
If you like the pod, give us a five star review wherever you rate your favorite podcast.
00:56:36.199 --> 00:56:37.130
Thank you for listening.
00:56:37.130 --> 00:56:38.239
Yay.