Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

Post reply on HN
Print view View original

251–259 of 259 posts

Re: Memory Integrity Enforcement

#251

Post by strcat »

HackerNewt-doms wrote: post #156
strcat wrote: post #86

Earlier quoted context omitted.

GrapheneOS made our own integration of MTE for hardened_malloc and has done significant work on it. It wasn't simply something we turned on. ARM designed and built the feature which was made available in Cortex cores. Google's Tensor uses standard Cortex cores so unlike Qualcomm they didn't need to make their own implementation. Google integrated it into Android and did some work to make it available on Pixels along…

Is MTE on GrapheneOS restricted to some (newest?) Pixel models? Or does it work with all models that are currently supported by GrapheneOS itself?

It's available since October 2023 when it launched on the Pixel 8. We integrated it into hardened_malloc that month and deployed it in production. We've been working on further research and improvements based on MTE since then.

GrapheneOS always uses it for the kernel, all of the base OS processes including apps with a couple exceptions, user installed apps opting into it and user installed apps solely written in Java/Kotlin which are very common on Android. For other user installed apps, there's a toggle for users to opt-in and most apps work with it already. For apps not known to work with it, there's a user-facing system for MTE crash reports and users can make an exception. Users can't disable it for base OS apps or apps which should work due to opting in or being pure Java/Kotlin.

Apple uses it for the kernel and parts of the base OS. They require opt-in by app developers and discourage doing it.

GrapheneOS is working on improvements to the kernel integration, Chromium PartitionAlloc integration and other aspects of it. We'll enable enforcement of tags for untagged memory once that's available, but we're also expanding the tagging. As an example, fully enabling stack allocation tagging has a more than acceptable performance cost for GrapheneOS but not Apple or Google. That's something we've been actively testing and will be deploying.

Re: Memory Integrity Enforcement

#252

Post by [deleted] »

saagarjha wrote: post #183
strcat wrote: post #103

Earlier quoted context omitted.

> Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons. If that's the case, then many of their public statements about this are extraordinarily dishonest. There are widespread exploits targeting Safari, Chrome, iOS and Android. These are not only rare attacks targeting people heavily sought out by governments, etc. They do not have nearly as much visi…

I don't really agree with your framing.

[deleted]

Re: Memory Integrity Enforcement

#253

Post by strcat »

saagarjha wrote: post #183
strcat wrote: post #103

Earlier quoted context omitted.

> Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons. If that's the case, then many of their public statements about this are extraordinarily dishonest. There are widespread exploits targeting Safari, Chrome, iOS and Android. These are not only rare attacks targeting people heavily sought out by governments, etc. They do not have nearly as much visi…

I don't really agree with your framing.

I disagree with corporations marketing misrepresenting their security capabilities to sell more devices and services. Apple and Google are much better at security than most tech companies but definitely nowhere near as successful as Apple's marketing portrays it.

Re: Memory Integrity Enforcement

#254

Post by strcat »

ysnp wrote: post #173
HackerNewt-doms wrote: post #156

Earlier quoted context omitted.

Is MTE on GrapheneOS restricted to some (newest?) Pixel models? Or does it work with all models that are currently supported by GrapheneOS itself?

MTE is only available in hardware on Pixel 8 and later https://googleprojectzero.blogspot.com/2023/11/first-handset... . GrapheneOS supports all the Pixel 8 and 9 series phones. They plan to support Pixel 10 once Google stop delaying their open-source releases of AOSP.

MTE is also available on a bunch of non-Pixel devices we can't support or which don't meet our other requirements.

8th/9th generation Pixels are half of the devices we support. 7 years of support is the status quo but it was 3 years before the Pixel 6 raised it to 5 so the earlier devices aren't supported anymore.

Re: Memory Integrity Enforcement

#255

Post by strcat »

saagarjha wrote: post #189
strcat wrote: post #100

Earlier quoted context omitted.

The side channel fixes and new MTE instruction features are not specific to Apple. Apple's blog post has some significant misleading claims and omissions. It's marketing material, not a true technical post without massive bias. It's aimed at putting down the existing deployments of MTE, hyping up what they've done and even downplaying the factually widespread exploits of Apple devices which are proven to be happening…

The choices they made are novel to my understanding.

There's a difference between Apple doing good integration of MTE and the work they're doing being truly novel. ARM MTE is not the only memory tagging implementation. Apple getting ARM to add something many people have wanted from elsewhere is useful, but it doesn't make it their idea. The fact is that they're not at all the first to deploy MTE to production and MTE was not the first deployment of hardware memory tagging to production. Their integration is better than what Google offers in Android 16 themselves. Unlike Apple, Google's mobile OS is open source and not limited to what Google does themselves. There are ways their integration is better than what's implemented elsewhere and also ways that it's worse. For one thing, it's deployed for a narrower set of components. What's implemented elsewhere is not static and will improve. MTE has been deployed in production in GrapheneOS for 2 years without significant hardware changes yet, but those are coming.

Re: Memory Integrity Enforcement

#256

Post by saagarjha »

strcat wrote: post #253
saagarjha wrote: post #183

Earlier quoted context omitted.

I don't really agree with your framing.

I disagree with corporations marketing misrepresenting their security capabilities to sell more devices and services. Apple and Google are much better at security than most tech companies but definitely nowhere near as successful as Apple's marketing portrays it.

I agree but I really have no idea how to fix this.

Re: Memory Integrity Enforcement

#257

Post by saagarjha »

strcat wrote: post #250
saagarjha wrote: post #190

Earlier quoted context omitted.

Disclaimer: I have never worked with the team on the Apple side. My impression is that Apple's threat intelligence effort is similar in quality to Google's. Of course external parties also help but Apple also independently finds chains sometimes.

> My impression is that Apple's threat intelligence effort is similar in quality to Google's. We have a lot of direct experience with Google not having much of a clue about how their own devices are being exploited in the wild. The overall approach does not provide as much insight as it's marketed as doing.

Ok, come on, be reasonable. You finding a Cellebrite price list does not mean you know more about how Pixels are targeted than Google because their marketing team put something out saying they’re super hard to hack. I have worked directly with Google’s threat research teams and they are well aware of their limitations while also having better insight than you’re giving them credit for.

Re: Memory Integrity Enforcement

#258

Post by chalst »

jrtc27 wrote: post #192
checker659 wrote: post #178

Earlier quoted context omitted.

> compile-and-link layer Not to mention the dynamic linker.

Yeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The c…

Homepage here:

  https://www.cheribsd.org/
which strangely doesn’t seem to link here:

  https://github.com/CTSRD-CHERI/cheribsd

Re: Memory Integrity Enforcement

#259

Post by saagarjha »

strcat wrote: post #255
saagarjha wrote: post #189

Earlier quoted context omitted.

The choices they made are novel to my understanding.

There's a difference between Apple doing good integration of MTE and the work they're doing being truly novel. ARM MTE is not the only memory tagging implementation. Apple getting ARM to add something many people have wanted from elsewhere is useful, but it doesn't make it their idea. The fact is that they're not at all the first to deploy MTE to production and MTE was not the first deployment of hardware memory tagg…

Apple did not just “get ARM to add something” they got dozens if not hundreds of engineers to think really hard about how to roll out MTE with no performance impact on all their critical attack surface in a way that actually targets specific exploit strategies rather than just going “oh ok our allocator has tags now”. Google (and Android) took a very different approach. Of course it’s very possible Apple messed up and their implementation is not as secure as it was designed to be but they did put significant effort in many areas that I feel are novel.
Post reply on HN