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

GrapheneOS finds Bluetooth memory corruption via ARM MTE

grapheneos.social

Post reply on HN
Print view View original

211–220 of 228 posts

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#211

Post by resource_waste »

ForHackernews wrote: post #209
resource_waste wrote: post #205

Earlier quoted context omitted.

Buddy, 1000+ people got their iPhones cracked by pegasus, at least 1 person was killed and bezos had his noods leaked. Yeah google does a better job.

I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models. Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.

Yes, my super expensive secret is way more valuable than getting ads about my hemorrhoids.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#212

Post by jacooper »

strcat wrote: post #184
jacooper wrote: post #133

Earlier quoted context omitted.

Try disabling rerouting for Geolocation requests to GrapheneOS, because I personally found the gps provider integrated in it to be almost unusable, since it doesn't implement Bluetooth/wifi scanning at all. Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.

We're going to provide other network location providers including local ones. The existing ones aren't up to our standards which is why we didn't simply bundle them. In theory, we could also support toggling on the less privacy SUPL mode which leaks your location to the SUPL server but can get location without GNSS satellite reception.

Would be great, as giving google my location doesn't feel great.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#213

Post by strcat »

saagarjha wrote: post #200
strcat wrote: post #188

Earlier quoted context omitted.

They have already fixed nearly all the crashes in the base OS. The issues we face are almost entirely regressions in new versions. They fix them consistently but they aren't stopping the regressions getting into releases because they don't use MTE in production.

Regressions from whom?

Regressions in Android because they aren't doing enough real world testing with MTE or HWASan builds. They're clearly testing them via CI and fixing those issues but in real world usage more issues are uncovered which often slip into releases then get fixed in another release a few months later.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#214

Post by [deleted] »

surajrmal wrote: post #198
strcat wrote: post #104

Earlier quoted context omitted.

It's based on communication with them. We've had it directly communicated to us. There are also multiple Google security engineers/researchers who liked/retweeted our posts. Google has stated the Pixel 8 is the first platform with MTE available in production devices, so it's not a large jump to the hardened alternate OS available for it being the first to deploy it in production. We have ~250k users on Pixels, and th…

I feel like you're complaining, but it seems like Google has made historic advancements simply by pushing this technology to the point it's available and fixed most of not all crashes it finds. Stopping short of the goal by not enabling it on prod is likely a well reasoned choice. Google is highly committed to the underlying technology. It doesn't seem like the door to having it enabled in prod is forever closed and…

[deleted]

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#215

Post by strcat »

surajrmal wrote: post #198
strcat wrote: post #104

Earlier quoted context omitted.

It's based on communication with them. We've had it directly communicated to us. There are also multiple Google security engineers/researchers who liked/retweeted our posts. Google has stated the Pixel 8 is the first platform with MTE available in production devices, so it's not a large jump to the hardened alternate OS available for it being the first to deploy it in production. We have ~250k users on Pixels, and th…

I feel like you're complaining, but it seems like Google has made historic advancements simply by pushing this technology to the point it's available and fixed most of not all crashes it finds. Stopping short of the goal by not enabling it on prod is likely a well reasoned choice. Google is highly committed to the underlying technology. It doesn't seem like the door to having it enabled in prod is forever closed and…

We have active communication with many people at Google about the areas we're heavily working on such as this and are not basing this on assumptions. You're talking about what you think happened based on your assumptions about it from lightly reading about it.

Most of the crashes were fixed via HWAsan before MTE existed in hardware. Their security people want MTE enabled in production. These issues were fixed before MTE and would have been fixed whether or not MTE was available in the standard ARMv9 cores/cache used by Pixels. MTE would likely already be enabled in production for the base OS (not user installed apps) if there weren't performance concerns. They clearly integrated it with that intention. We're more than capable of reading the commit messages and talking to engineers who worked on it along with other contacts there. They aren't keeping it a secret that there's a clear goal to enable MTE in production.

ARM provided MTE in their standard ARMv9 Cortex core designs. That's why MTE is available on the Pixel 8 and Pixel 8 Pro, because Tensor currently uses the standard core/cache designs. That's why MTE is not available for Snapdragon, and it's why it is theoretically available for MediaTek and Exynos.

The current availability of a high performance MTE implementation doesn't mean Google is highly committed to it. Pixels will be moving from standard Cortex core designs to their own core designs. There's an open question about whether MTE will be supported in the same way it is now. You're assuming that they're heavily committed to it and going to keep providing an extremely low overhead implementation. We have concrete reasons to be concerned.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#216

Post by strcat »

acqbu wrote: post #210
trompetenaccoun wrote: post #208

Earlier quoted context omitted.

How do you have privacy without security? If it's less secure it enables more attacks where your private data could be compromised.

Security isn't something you have or not. There's nuances. CalyxOS makes a few trade-offs which I'm happy to accept in order to be able to use several banking apps, Google pay, wallet etc.

You have this completely backwards.

GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.

GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.

CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.

Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:

https://grapheneos.org/usage#sandboxed-google-play

Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#217

Post by strcat »

acqbu wrote: post #204
nelblu wrote: post #27

Earlier quoted context omitted.

Not exaxtly grapheneOS but close enough CalyxOs has started supporting Fairphone 5 and it has replaceable batteries AFAIK: https://calyxos.org/news/2024/03/05/fp5/

CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.

You have this completely backwards.

GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.

GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.

CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.

Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:

https://grapheneos.org/usage#sandboxed-google-play

Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#218

Post by strcat »

trompetenaccoun wrote: post #208
acqbu wrote: post #204

Earlier quoted context omitted.

CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.

How do you have privacy without security? If it's less secure it enables more attacks where your private data could be compromised.

They have this completely backwards.

GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.

GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.

CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.

Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:

https://grapheneos.org/usage#sandboxed-google-play

Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#219

Post by strcat »

SushiHippie wrote: post #57
freedomben wrote: post #38

Earlier quoted context omitted.

Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.

Though the pixel 4 still gets updates from GrapheneOS, which didn't receive updates since October 2022 from Google. So they support it even a bit longer than google officially does.

Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#220

Post by strcat »

chasil wrote: post #194
strcat wrote: post #181

Earlier quoted context omitted.

They can have up-to-date AOSP but a significant portion of the OS consists of the driver, HALs, non-GKI kernel tree, etc. Android security patch level is meant to cover all of that. They're using it in a way that's not permitted for Android OEMs by redefining it to mean AOSP patch level for the parts of AOSP they build. Some things get built from AOSP for vendor executables and that are built into vendor executables.…

Once again, thank you for this perspective. I had no idea that a library was presented by the bootloader (AVB). Interesting reading. https://android.googlesource.com/platform/external/avb/

Pixels largely use open source code for the parts specific to Pixels (TEE, secure core, secure element, boot chain) but unfortunately they don't publish all the Pixel specific changes yet. They committed to publishing the firmware and hardware sources for the Titan M but provided no timeline and clearly didn't mean they would publish the sources for the current revisions but rather future ones. There's the OpenTitan project which they seem to use as a base since the Pixel 6 but that isn't what they committed to doing. We're still waiting for this and hoping they do it soon so that we can help audit this and report better bugs when we run into issues.
Post reply on HN