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

91–100 of 228 posts

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#91

Post by pomian »

wafflemaker wrote: post #12

Hope somebody using Graphene OS could answer: 1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions? 2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?

Super easy install via USB cable to laptop, running Windows and Firefox. Read through the instructions once. (For - example they suggest turning phone on with stock Os, and activating all important features on the phone. Then it's a few clicks, and about 10-20 minutes it's all installed. We have a Pixel 4xl and a 5, and everything just works. No crashing. And all updating.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#92

Post by stevenae »

jetbalsa wrote: post #81
gausswho wrote: post #77

Earlier quoted context omitted.

I've been very happy with GrapheneOS on my Pixel 7, for the year that I've had it. The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing. Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?

Android Auto is not yet supported in GrapheneOS and that's pretty much half the usage of my phone gets on a daily basis

Is that up to date? Their site describes support

https://grapheneos.org/features#android-auto

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#93

Post by strcat »

dtx1 wrote: post #2

GrapheneOS is so far ahead in terms of security than anything else that it makes chosing anything but pixel hardware really questionable. But I REALLY want replaceable batteries. Why does everything have to suck nowadays?

Pixels are currently the only devices meeting our security requirements. Other Android devices don't even come close. Hardware memory tagging support is one of many major security advantages of Pixels. Our official list of hardware requirements is available here: https://grapheneos.org/faq#future-devices. These requirements are fully provided by 8th generation Pixels. 6th/7th generation Pixels are only missing MTE, BTI and PAC but MTE is the most valuable feature on the list of hardware requirements. Proper security patches are even more important, which are not available in the same way outside Pixels.

Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS.

The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available:

https://www.ifixit.com/Device/Google_Pixel

We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#94

Post by gspencley »

wafflemaker wrote: post #12

Hope somebody using Graphene OS could answer: 1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions? 2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?

It's easy to install and for 99% of use-cases the OS is just as convenient as any other Android phone.

However, recently my wife and I travelled to Orlando Florida to visit Disney World and Universal Studios. While their apps mostly worked with sandboxed Google Play Services, I did have some annoying issues. The My Disney Experience app gave me a lot of glitches related to Location (it was intermittent but I would occasionally be told I need to be in US or Canada to do something important and we had to use my wife's phone as a workaround) and I found myself unable to log in to my account on the Universal App (again, worked fine on my wife's stock Samsung Galaxy so pretty sure it was GrapheneOS).

Another limitation is that if you use Google Wallet to make credit card payments, this is unsupported since Google will not certify GrapheneOS. Wallet does work otherwise.

Uber works just fine for me. Other than that, I don't use any proprietary apps.

If you intend to stick mostly to FOSS apps you shouldn't have any issues. Most proprietary apps will work with sandboxed Google Play Services, but if any of those are mission critical for you then be warned that you might run into some annoying issues like I did with Universal Studio & My Disney Experience.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#95

Post by saint_yossarian »

wafflemaker wrote: post #12

Hope somebody using Graphene OS could answer: 1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions? 2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?

Regarding 2, a couple of things to watch out for:

- There's no Google cloud backup, it uses Seedvault instead. It was a bit of a pain setting up some apps from scratch again (those that didn't have other backup mechanisms), but if I ever reinstall or switch to another phone running GrapheneOS I can copy over the backups and presumably restore them. It also supports some remote storage providers, but I haven't bothered with those yet.

- There's no Google Digital Wellbeing, which I used to track screen time and set limits for some apps. There are some limited alternatives on F-Droid, but I just ended up using Tasker to give me reminders when I'm staring at the screen for too long.

Other than that I didn't have any problems, and really enjoy the privacy features. Especially the ability to block network access per app, and set up custom storage scopes.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#96

Post by strcat »

moonshot5 wrote: post #65
xvector wrote: post #36

> Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode. I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to di…

AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind. I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore th…

> AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind.

AOSP also only directly supports the phones/tablets we support. We were only talking about 2 of the devices supported by AOSP. Pixels enabling MTE is not connected to other devices. App compatibility is also not an issue because it can be enabled for the base OS with user installed apps excluded until they opt into it. It can be made opt-out in a future target API level (Android 15) and then the opt-out can be removed in the next target API level. This is entirely doable.

> I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.

We're not ignoring it. We're talking about the Pixel 8, Pixel 8 Pro and future Pixels. It's a request for Pixels to enable it, not AOSP to enable it for all devices.

> I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.

Performance and memory usage are definitely the only blocker to enabling it for the base OS. It would already be enabled if the security team was in charge of these decisions. It's not enabled because they likely have to prove it's fast enough. Our specific recommendation was enabling it in asynchronous mode for all cores for the base OS and user installed apps explicitly opting into it. We do not think it's a good idea to start automatically opting apps into using it until more Android devices support it. Google could require that ARMv9 devices support MTE as a developer option for Android 15 onwards in the CDD in order to make sure developers have it available for testing. App developers can't be expected to have a Pixel so it's unrealistic to have it forced on app developers via target API level until more devs have devices available to test it. We understand all that and what we are pushing for takes that into account.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#97

Post by gray_-_wolf »

digging wrote: post #33
gray_-_wolf wrote: post #16

Earlier quoted context omitted.

As a former user: 1. Installation is easy, assuming your phone is supported, you can even install it via Chrome-based browser with regular USB cable. 2. Great for daily use, no crashes. Bank app might or might not work, depends on the bank.

Maybe the real question here though is: Why former?

Because the pixel I got suffered from connectivity loss (even on official ROM, not a GrapheneOS problem) and I needed a reliable phone for holding on-calls. :/ It is a shame, I really liked the system.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#98

Post by strcat »

loeg wrote: post #51
xvector wrote: post #36

> Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode. I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to di…

The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature.

> The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature.

We're only proposing enabling it for the base OS and user installed apps opting into it. Google has already fixed nearly all the crashes due to testing with HWAsan and MTE. They don't test enough with real world usage yet because they haven't deployed it for all the dogfooding devices. To do that, they need to set up enabling it for the base OS without enabling it for all user installed apps because that's not currently very practical. Google has already done most of the work for enabling it for the base OS, not us. We have to fix some bugs, but they're almost all regressions which don't live past the next quarterly releases since they do find and fix them. Google is 100% capable of enabling MTE for the Pixel stock OS within the base OS without a significant increase to crashes for users. In fact, it will significantly decrease user-facing crashes once it matures. It will result in so many memory corruption bugs being fixed. Testing internally with MTE doesn't do the same thing as deploying it to production in terms of bug fixing and also doesn't provide hardening against the bugs not occurring during regular usage.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#99

Post by mewse-hn »

snoutie wrote: post #60
hackerman3309 wrote: post #52

Earlier quoted context omitted.

[flagged]

I might have not caught that he tried to kill graphene os. Didn't he just say that he decided to not use gOS anymore because he thinks that the developer of gOS might have something against him personally? Anyway, I don't know a single person who stopped using gOS because of the feud between these two Gladly I might add since I have been enjoying gOS so far

  Anyway, I don't know a single person who stopped using gOS because of the feud between these two
I'm looking into leaving the iOS ecosystem because the new devices are forcing faceID, and Rossman's experience with Graphene has made me very, very wary of buying into it.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#100

Post by nani8ot »

talhah wrote: post #49
jstanley wrote: post #17

Earlier quoted context omitted.

1. No, it was very easy. I used a normal USB cable and adb on the Linux command line, but the recommended method involves using Web USB in Chromium which is meant to be easier for non-technical people but I couldn't get it to work. 2. No, it is very convenient. It has a sandbox for Google Play Services, which IMO is the best of both worlds as it means you can install all the proprietary crapware apps that make modern…

Do things such as Gcam and Google Pay work? The two major things I need from my phone is good camera quality and being able to use Google Pay which is useful where I'm at.

Some banks have their own contactless payment app, which can be set as default in GrapheneOS (or any Android). Most banking apps work, as long as they use AOSP's hardware attestation feature instead of Google's SafetyNet, which requires the same Google device certification as GPay.

[1] https://grapheneos.org/usage#banking-apps

Post reply on HN