Comment by strcat | Hacker News Reader

Comment by strcat | Hacker News Reader

Parent Full thread

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 with fixing many bugs it uncovered, although definitely not all of them. We had to fix many of the issues. Apple had to make their own hardware implementation because they have their own cores, which Qualcomm finally got done too.

Pixels are not the only Android devices with MTE anymore and haven't been for a while. We've tried it on a Samsung tablet which we would have liked to be able to support if Samsung allowed it and did a better job with updates.

GrapheneOS is not a 1 person project and not a hobby project. I wasn't the one to implement MTE for hardened_malloc and have not done most of the work on it. The work was primarily done by Dmitry Muhomor who is the lead developer of GrapheneOS and does much more development work on the OS than I do. That has been the case for years. GrapheneOS is not my personal project.

We've done a large amount of work on it including getting bugs fixed in Linux, AOSP and many third party apps. Our users are doing very broad testing of Android apps with MTE and reporting issues to developers. There's a specific crash reporting system we integrated for it to help users provide usable information to app developers. The hard part is getting apps to deal with their memory corruption bugs and eventually Google is going to need to push for that by enabling heap MTE by default at a new target API level. Ideally stack allocation MTE would also be used but it has a much higher cost than heap MTE which Apple and Google are unlikely to want to introduce for production use.

Android apps were historically largely written in Java which means they have far fewer memory corruption bugs than desktop software and MTE is far easier to deploy than it otherwise would be. Still, there are a lot of native libraries and certain kinds of apps such as AAA games with far more native code have much bigger issues with MTE.

None of this is wrong but none of this really has any impact on what Apple decided to do. In fact Apple very specifically chose not to go in this direction as they describe in their blog post.

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. If they're not aware of how widespread the exploits of their devices are including by low level law enforcement with widely available tools, that's quite strange.

I think you have to read "widespread malware attack" in Apple lit as a term of art; it's a part of the corporate identity dating back to the inception of the iPhone and (I think maybe) ties into some policy stuff that is very salient to them right now. I think SEAR is extremely aware of what real-world exploitation of iPhones looks like. You were never going to get their unfiltered take in a public blog post like this, though.

> I think you have to read "widespread malware attack" in Apple lit as a term of art

There's widespread exploitation of Apple devices around the world by many governments, companies, etc. Apple and Google downplay it. The attacks are often not at all targeted but rather you visit a web page involving a specific political movement such as Catalan independence and get exploited via Safari or Chrome. That's not a highly targeted attack and is a typical example of how those exploits get deployed. The idea that they're solely used against specific individuals targeted by governments is simply not true. Apple and Google know that's the case but lead people to believe otherwise to promote their products as more safe than they are.

> I think SEAR is extremely aware of what real-world exploitation of iPhones looks like.

Doesn't seem that way based on their interactions with Citizen Lab and others.

I understood the point you were making previously and was not pushing back on it. I think you're wrong about SEAR's situational awareness, though. Do you know many people there? I'd be surprised if not. Platform security is kind of an incestuous scene.

We have regular contact with many people at Google in that space and nearly no contact with anyone at Apple as a whole. Sometimes people we know go to work at Apple and become nearly radio silent about anything technical.

It's often external parties finding exploits being used in the wild and reporting it to Apple and Google. Citizen Lab, Amnesty International, etc.

We regularly receive info from people working at or previously working at companies developing exploits and especially from people at organization using those exploits. A lot of our perspective on it is based on having documentation on capabilities, technical documents, etc. from this over a long period of time. Sometimes we even get access to outdated exploit code. It's major releases bringing lots of code churn, replaced components and new mitigations which seem to regularly break exploits rather than security patches. A lot of the vulnerabilities keep working for years and then suddenly the component they exploited was rewritten so it doesn't work anymore. There's not as much pressure on them to develop new exploits regularly as people seem to think.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com