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

181–190 of 228 posts

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#181

Post by strcat »

chasil wrote: post #167
strcat wrote: post #150

Earlier quoted context omitted.

We have extended support for end-of-life devices but discourage using it and make it clear that it's insecure. We dislike needing to provide it and many people don't realize we do because we make sure not to hype it up and instead try to get people to move to secure devices with full patches available. 6th gen Pixels moved to 5 year minimum support from launch and 8th gen moved to 7 years so we do not think extended…

That is interesting and useful discussion. I do wonder what I am seeing on Lineage with an older device, where the OS security is current, but the vendor security is long out of date.

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. As an example with firmware, it will use the AVB library in the bootloader firmware. It also gets built into userspace driver libraries which are often proprietary, etc. Updating the portion of the OS they build via AOSP is not quite updating all the code from AOSP, and even if it was, the Android security patch level is not only for AOSP code. It covers firmware, drivers, etc. Check the recent Android Security Bulletins. The split Vendor security patch level shown in Settings is a LineageOS invention to show the REAL patch level for the overall device including firmware, drivers, HALs, kernel, etc. The whole point is meant to be that it's an overall patch level though. We just set the real patch level for extended support devices while providing the AOSP releases/backports. The only problem is the other alternate OSes making it look as if they're providing something more, but we aren't going to stop using it the official way. We're just not going to need extended support after the Pixel 5a since devices moved to 5 years and then 7 years of proper support.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#182

Post by strcat »

Sytten wrote: post #161
strcat wrote: post #110

Earlier quoted context omitted.

GrapheneOS provides extended support for end-of-life devices but we strongly discourage using our extended support releases. You can see we do that from https://grapheneos.org/releases and https://grapheneos.org/faq . We set an accurate Android security patch level field and do not downplay it with inaccurate claims about it. We do not do what other alternate operating systems by splitting out a Vendor security patch…

I understand that from a security perspective, but from an e-waste perspective even the current 7 years support is disastrous let alone the previously 3-5 years that vendors. Not everybody has the same security needs, I often gift my older phones to my family members and if I have the choice to leave them on a fully unpatched device vs a GrapheneOS that is a "best effort" patch I will happily choose GrapheneOS. I am…

Extended support is very difficult to provide in a way that fits into the expectations we have for robustness, app compatibility and security beyond the lack of incomplete patches. For example, it would be easiest for us to move the Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 to avoid having a separate legacy Android 14 QPR1 branch where we need to apply backported AOSP patches which sometimes don't apply cleanly. However, the Pixel 4a (5G) and Pixel 5 do not officially supported Android 14 QPR2 but yet had a bunch of changes related to it done to their repositories. We also build the vendor image ourselves rather than using a prebuilt one, so it always gets built with the latest SELinux policies, HALs, etc. available in AOSP. Quarterly releases are now trunk-based so it's similar to the major yearly releases. Moving Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 is entirely possible. We could revert the QPR2 changes for them and use a QPR1 vendor build. The issue is that we know there are going to be regressions, and we do not want to ship dozens of serious bugs to users which we then have to invest substantial time in resolving. It's all time taken away from our focus on privacy features, security features, trying to have perfect app compatibility beyond apps forbidding using a non-Google-certified OS, etc.

We're very happy that support increased to 5 years for 6th generation devices and then 7 years for 8th generation devices because we will no longer feel the need to do harm reduction via extended support. It will save us a huge amount of time and concern about people continuing to use these insecure devices.

7 years for a phone that's used as a main personal phone is a long time. Most people aren't going to use it that long, particularly a flagship phone. It mostly benefits people buying it used. It would be quite strange to buy a Pixel 8 Pro and use it for all 7 years. The audience for using a phone that long is probably going to buy a cheaper phone. The main benefit is to someone buying a used device where it still has 4 years of support after someone replaces it after 3 years. We aren't a fan of people unable to afford new phones getting insecure used devices. This is a big step towards that not happening anymore. 7 years is longer than iPhones have been getting full support updating them to the new major OS releases with full security patches.

We worry a lot that we're encouraging people to keep using insecure devices by providing extended support but we feel we have to provide it with how many people are clearly still using the end-of-life devices. However, how much of the amount of people still using them is because they think they are fine due to continued GrapheneOS support? This bothers us.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#183

Post by strcat »

kaba0 wrote: post #135
strcat wrote: post #134

Earlier quoted context omitted.

No, that's not correct and what you're stating about my views or what I have said is not correct. > Daniel Micay himself said that iphones are one of the best choices from a security perspective, GrapheneOS closing the gap. I haven't said this about current era GrapheneOS. You're referring to outdated comments from 4 years ago. Pixels, AOSP and GrapheneOS have all massively improved since then. Pixels with the stock…

I didn’t mean to misrepresent your views, was only remembering an old comment of you that said that iphones are quite good for the security-minded. Of course I could not have known how the state of security, or your opinion of it has changed in the meanwhile.

You're correct that it was my position at one point, but it was around 4 years ago and a lot has changed. We did used to say iPhones were more secure from 2014-2019 but it started shifting in 2020 and then especially in 2021-2022 as AOSP, Pixels and GrapheneOS got to the point where we were confident what we provide is better overall for security. It's the same for privacy now overall, but there are areas where iOS does better on privacy and we're prioritizing fixing that by doing better than iOS in those areas such as clipboard privacy where Android is still weaker.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#184

Post by strcat »

jacooper wrote: post #133
gspencley wrote: post #94

Earlier quoted context omitted.

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 oc…

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.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#185

Post by strcat »

trompetenaccoun wrote: post #149
strcat wrote: post #140

Earlier quoted context omitted.

> 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. There's a bug on many Linux distributions which was fixed in fwupd but is still present because they haven't updated it to a recent version. It interferes with reconnecting to the device when it reboots into fastbootd mode as part of the install. We cover it in our install gu…

Since you seem to be on the Graphene team, may I piggyback on this: I've been wanting to make the switch over from iOS for some time but it bothers me a bit that I have to buy a Google phone. Are there any plans to support non-Google devices? I know this has been discussed and the answer I've seen is that Google devices are the best fit, but at least one more option would be nice.

The hardware requirements are listed here:

https://grapheneos.org/faq#future-devices

Pixels are the only Android devices meeting these requirements at the moment. Other devices do not currently come close to meeting these standards. This post is about MTE which is essentially a Pixel exclusive feature.

Simply receiving monthly and quarterly updates is essentially a Pixel exclusive feature and using an alternate OS providing them still leaves major parts of the firmware/OS without those improvements.

2 of the features on the requirements list are proposals we made to them which were accepted / implemented. There's another one of these pending for protection against data extraction via physical access through exploiting firmware boot modes on After First Unlock devices. Supposed to ship in April, and then we can add it to the list. The non-truncated key fingerprint display (we reported truncating it as a vulnerability) and the fantastic pinning-based hardware attestation support used by our Auditor app are the existing 2.

We've tried working with other OEMs but it hasn't panned out yet. We're often quite frustrated by Google but you'd probably be surprised at how much they have done based on our requests.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#186

Post by strcat »

gausswho wrote: post #77
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?

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?

Pixels only support digital USB-C audio output. USB-C also has a lot of compatibility issues beyond this from non-spec-compliant cables, peripherals, chargers, ports, hubs, etc. Google and Apple have a perfectly good USB-C DAC which is far higher quality than the DAC included for the analog jack on older Pixels, which are known to work well.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#187

Post by strcat »

heywherelogingo wrote: post #74
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?

Graphene is great, the problem is pixel phones. We need an effort to push other manufacturers to get on board.

We provide a concrete list of requirements at https://grapheneos.org/faq#future-devices which we're trying to extend with as much of the unstated requirements as possible. Quality of implementation matters though.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#188

Post by strcat »

saagarjha wrote: post #164
strcat wrote: post #98

Earlier quoted context omitted.

> 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 b…

I don’t understand your argument here. Google has been working on fixing the their own crashes with the data they have right now. Why would they turn it on for everyone else while they do that?

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.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#189

Post by strcat »

brcmthrowaway wrote: post #170
gchadwick wrote: post #166

Earlier quoted context omitted.

CHERI provides actual hardware enforced protection. MTE exists to find potential security bugs but no real protection. You've got a 4 bit tag, which an application can forge so if some attacker needed to forge the correct tag they could choose randomly and be right 1/16th of the time. The idea is when MTE is employed you'll get bad accesses occurring occasionally that aren't due to an attacker and don't actually caus…

Google should use CHERI

Ideally, but it's not realistic to convince them to do that yet. It is very realistic to convince them to use asynchronous MTE for the base OS and their own apps. The more secure asymmetric MTE is a much harder sell, but would be way nicer for security.

Re: GrapheneOS finds Bluetooth memory corruption via ARM MTE

#190

Post by strcat »

ysnp wrote: post #159
strcat wrote: post #147

Earlier quoted context omitted.

MTE is an optional feature for ARMv8.5 and is only available via ARMv9 in practice. Snapdragon doesn't provide it but they told us they're likely going to add it by 2025/2026. Pixel 8 and Pixel 8 Pro are the main option with it. MediaTek and Exynos have theoretically added support for it but that doesn't mean any device with their latest flagship SoC theoretically supporting it actually has it available and working.

Is Snapdragon hardware present in the current/upcoming lineup of Pixel devices such that MTE support is relevant to GrapheneOS?

We want to support other devices and consider this the main blocker because Exynos is not widely used outside Samsung and Snapdragon is better at overall security than MediaTek. Qualcomm dropped the ball on MTE but they're quite good at security overall. It doesn't matter outside our perspective because MTE is not being used in production by others yet, which is why Qualcomm didn't prioritize it.
Post reply on HN