[HN Gopher] GrapheneOS finds Bluetooth memory corruption via ARM...
___________________________________________________________________
GrapheneOS finds Bluetooth memory corruption via ARM MTE
Author : gaul
Score : 245 points
Date : 2024-03-11 13:36 UTC (9 hours ago)
(HTM) web link (grapheneos.social)
(TXT) w3m dump (grapheneos.social)
| dtx1 wrote:
| 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?
| Sytten wrote:
| Agreed but they do drop support for older pixel devices very
| very quickly which is kinda of PITA. At least the Pixel 8 is
| supposed to be supported 7 years.
| freedomben wrote:
| 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.
| SushiHippie wrote:
| 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.
| chasil wrote:
| Taking the "vendor security patch level" into account, it
| is impossible in some situations.
|
| If a critical vulnerability is found in a Qualcomm modem,
| wifi, or bluetooth firmware, there may be scenarios where
| this cannot be fixed at the OS level.
| strcat wrote:
| 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 support will make sense after
| the Pixel 5a. For now, we reluctantly provide it. There's
| a good chance we'll port the end-of-life Pixel 4a (5G)
| and Pixel 5 to Android 14 QPR2 to keep providing what we
| call "extended support" with all AOSP/GrapheneOS changes
| instead of "legacy extended support" with just backported
| patches. It's very unfortunate they didn't just extend
| the 4a (5G) and 5 to match the 5a lifetime despite it
| having the same SoC. It makes our life harder.
|
| Android doesn't have a separate vendor security patch
| level. It has a single security patch level covering all
| of the Android security bulletin and OEM security
| bulletin patches. Most alternate operating systems set an
| inaccurate Android security patch level where they
| redefine it to mean AOSP patches. They added a separate
| Vendor security patch level to put the real patch level.
| The whole thing is strange because the whole point is
| having a simple overall patch level and being honest
| about it. The standard Android security patch level only
| includes Critical/High severity vulnerabilities now, not
| Moderate/Low severity, and it doesn't include a lot of
| things that are deemed optional or out-of-scope. Can see
| this by looking at the Pixel bulletins where there are
| tons of patches that are clearly generic AOSP patches for
| all devices and patches tied to components like the
| Exynos radio clearly used by other devices. Android
| Security Bulletin (ASB) and the patch level derived from
| it does cover a LOT of drivers/firmware, but far from all
| or even most.
|
| The missing patches for end-of-life devices include a lot
| more than outdated firmware in practice since drivers
| stop being updated and maintenance doesn't get taken over
| by others. The kernel drivers are open source but it
| doesn't mean someone takes over maintaining them. It's
| often mistaken as having all patches to open source code
| and missing patches to proprietary code but that's not
| accurate since updating AOSP is not updating all open
| source code. Lots of device specific code including even
| large parts of firmware is open source. As an example,
| Pixels use Trusty OS for the TEE and secure core,
| littlekernel for the boot chain firmware, etc. Security
| patches to those open source projects are security
| patches requiring new signed firmware updates to be
| released despite being open source patches.
| chasil wrote:
| 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.
| strcat wrote:
| 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 level field and claiming to provide all open
| source patches which is fundamentally not possible
| especially considering that a lot of the firmware is based
| on open source projects.
| strcat wrote:
| 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
| level field and claiming to provide all open source patches
| which is fundamentally not possible especially considering
| that a lot of the firmware is based on open source projects.
|
| Our hardware security requirements are listed at
| https://grapheneos.org/faq#future-devices. Pixels are the
| only devices providing the requirements we set for updates
| and the list of security features. They also provide proper
| alternate OS support where all those security features work
| correctly. Samsung has most of the expected features and
| provides a similar length of support and number of major
| yearly updates but is missing the proper alternate OS
| support, MTE and the monthly/quarterly updates.
|
| Each month, there's a new Android release which are distinct
| from the partial backporting of privacy/security patches to
| older versions. It's not monthly security releases but rather
| monthly performance/security/feature releases with separate
| backports of all Critical/High severity patches to older
| versions. Android 14 and Android 14 QPR1 are older versions
| of Android, and there are security backports to Android 14
| separate from the monthly releases. This is currently fairly
| exclusive to Pixels. Samsung is getting much better at doing
| the security backports and are reducing delays for major
| updates but they're still acting as if the monthly/quarterly
| releases don't exist.
| Sytten wrote:
| 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 super glad for all the work you guys do in any case,
| you can only love from me and I am honestly not buying an
| phone that doesn't support GrapheneOS at this point.
| perlclutcher wrote:
| GOS's limited device support is disappointing, but I understand
| their reasoning. I still wish they'd release "GrapheneOS Minus"
| (in the vein of uBlock Origin Minus[0]) so a much larger
| audience could have 95% of the security benefits they'd have on
| Pixel hardware.
|
| As an alternative to replaceable batteries you could consider
| installing something like acc[1] to mitigate stress on your
| battery. My phone is 7 years old and the original battery still
| holds a charge like the day I bought it.
|
| [0]: https://github.com/uBlockOrigin/uBlock-
| issues/discussions/22...
|
| [1]: https://github.com/VR-25/acc
| strcat wrote:
| > GOS's limited device support is disappointing, but I
| understand their reasoning.
|
| Our specific hardware requirements are listed at
| https://grapheneos.org/faq#future-devices. It's a very
| concrete list of requirements there rather than subjective
| things. You can select a device and go through the list
| checking what's supported, and it will make sense why we
| can't support it. It's far more than a few minor things
| missing on other devices. They're missing basic things
| required to have features like encryption working for most
| users. Most Android devices don't meet bare minimum security
| requirements. At least 2 of the features we list exist
| because of us pushing for them from Pixels. There's another
| feature shipping around April which we proposed, and it will
| definitely be added to the list right away because it's
| critically important for defending against forensic data
| extraction before the device gets data back at rest via our
| auto-reboot timer after locking.
|
| > I still wish they'd release "GrapheneOS Minus" (in the vein
| of uBlock Origin Minus[0]) so a much larger audience could
| have 95% of the security benefits they'd have on Pixel
| hardware.
|
| It would not be anywhere close to providing 95% of the
| security benefits. In fact, it would largely be reducing
| security as the baseline without the hardware having proper
| alternate OS support. If you unlock a Samsung phone, the next
| closest to meeting our requirements, you cripple the device's
| security. Many of the hardware security features aren't
| available for an alternate OS and some even remain
| permanently disabled if you lock with the stock OS again. How
| can we support a device like that? Many of these hardware
| security features are what the OS security features are built
| on. Our work on integrating MTE into hardened_malloc and
| turning Android and Chromium's MTE support into something
| that can be used in production doesn't do any good on a
| device with no MTE, but this applies far beyond MTE. MTE
| alone is a significant part of the exploit protection
| advantages we're providing and is going to grow as we do more
| MTE integration work including potentially getting stack
| allocation MTE enabled in a way that doesn't break app
| compatibility (stack scanning by GC, etc.).
|
| Recommend reading through our security requirement list. It
| will make much more sense. It's not an exhaustive list of
| what we require but is what we were able to turn into clear
| concrete requirements which should be expected for all
| reasonably secure mobile devices.
| wafflemaker wrote:
| Wouldn't ripping out the backplate make the battery
| replacable?*
|
| Never heard of Google making installation of non genuine
| components hard the way Apple does.
|
| *If your hands are too clumsy to reconnect battery wires when
| swapping batteries, get a swiss knife.
| dtx1 wrote:
| In newer pixel models, everything is glued together. The
| Backplate is glued to the front, the battery is glued in so
| hard you can barely remove it and on top of it there's a
| graphene pad glued ontop of it for cooling reasons.
|
| Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Bat
| tery+Replacem...
|
| That's not "swiss knife" replacement.
| wafflemaker wrote:
| Wow. I genuinely thought that the replacement process was
| maybe a little more complicated than on the Samsung Note
| from 8 years ago that I did myself. That if you just ripped
| out the backplate you could have an ugly phone (not water
| resistant either) with a replacable battery. This
| complicated, time consuming and requiring specialized
| equipment process is not what I expected. Especially the
| part where you have to replace the screen you've just
| broken.
|
| Now I concur with the original poster in his lament on lack
| of new and fancy, yet fully owned by the user, phones that
| can cooperate with Graphene OS
| perlclutcher wrote:
| It's not that easy.
|
| https://www.ifixit.com/repairability/smartphone-scores
|
| > The battery is stubbornly glued down, and the soldered
| charge port can't be easily replaced.
|
| You have to take a heat gun to your phone to soften the glue
| to get the old battery out. Too little heat, the battery
| won't budge. Too much heat, you damage your screen or worse,
| ignite your battery. Good luck.
| IshKebab wrote:
| Well, maybe. But in this case I think the MTE work is in AOSP
| and they just turned it on.
| strcat wrote:
| No, that's not at all the case. We made our own MTE
| implementation for our hardened_malloc project with
| significantly stronger security properties. We had to fix
| multiple bugs in the OS and with Chromium's MTE integration
| to enable it for Vanadium in PartitionAlloc. We do currently
| simply use the standard implementation in PartitionAlloc but
| we plan to improve that since it's missing security
| properties we have in hardened_malloc. We also had to
| implement a system for per-app MTE control and an MTE crash
| reporting system. The current kernel KASan MTE backend is
| inadequate for usage of MTE as a hardening feature so we
| either need to make our own implementation there too or
| convince others to do it and it's likely not going to be the
| latter.
|
| ARM did the work of designing it and integrating it into
| their standard ARM Cortex core/cache designs. Google/Samsung
| did the work of preserving standard ARM functionality, unlike
| Qualcomm which currently loses it. Google/Samsung also had to
| integrate it into the boot chain. They'd already previously
| done most of the bug fixing work via testing with HWASan. It
| is certainly true that Google paved the way to use MTE with
| HWASan and did a lot of the bug fixing work in the OS but
| external security researchers did a lot of this work too.
| actionfromafar wrote:
| These phone cases with an integrated battery pack goes a long
| way towards replaceable batteries if you keep a stack of them.
| They probable put less strain and wear on the built-in battery
| too.
| dtx1 wrote:
| > They probable put less strain and wear on the built-in
| battery too.
|
| Nope, unless you can fore your phone to only charge to below
| 80% they strain the battery just as much if not more by
| keeping them at 100% all the time.
| alex-robbins wrote:
| This is false. It's true that staying at 100% is harder on
| lithium ion batteries than staying at 40%. However, the
| wear due to charge cycles is way, way more significant.
| Your battery will see much less wear if you keep it at 100%
| for some time vs discharging and recharging it a few times
| between (e.g.) 40% and 80% during that same time.
| actionfromafar wrote:
| I don't know how they do it, but some of these cases keep
| the phone at below 100%.
| worewood wrote:
| My S20 has an option to limit charge to 85%. It's already a
| reality.
| Tijdreiziger wrote:
| They seem to have long-standing problems with emergency
| services, though.
| https://www.reddit.com/r/GooglePixel/search/?q=emergency
| izacus wrote:
| Those posts are mostly more than a year old and many of those
| end up being VoLTE misconfiguration on carrier side which
| sadly affects many more phones than just pixels, e.g. iPhones
| too: https://www.reddit.com/r/iphone/comments/ynuu6c/newer_ip
| hone...
|
| VoLTE in general is quite the trash fire.
| nelblu wrote:
| 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/
| dtx1 wrote:
| Looking into that as an alternative for my dying pixel 3a but
| CalyxOS is to GrapheneOS what OpenBSD is to fedora when it
| comes to security. Both are good for updates and common
| security features but grapheneos has implemented security
| features that are a decade ahead of other Androids. Hardened
| Malloc, Playstore Sandbox instead of MicroG, Memory Tagging
| extensions, Selinux, bootloader Security, etc.
| strcat wrote:
| GrapheneOS and CalyxOS are very different. GrapheneOS is a
| hardened OS with substantial privacy/security improvements:
|
| https://grapheneos.org/features
|
| CalyxOS is not a hardened OS. It greatly reduces security vs.
| AOSP via added attack surface, rolled back security and slow
| patches. CalyxOS does not have features like this. It does
| the opposite of this.
|
| 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.
| strcat wrote:
| 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.
| dtx1 wrote:
| Thanks for the detailed explanation and i totally agree, it's
| not something i expect from graphene os, it's something that
| annoys me from googles pixels. I hope the new EU requirements
| to make reasonable battery swaps a thing means i get the best
| of both worlds.
| craftkiller wrote:
| Don't worry, GrapheneOS will drop support for your device
| before you need a battery replacement.
|
| (They support devices for slightly longer than the devices are
| supported upstream)
| oynqr wrote:
| Are you telling me my battery is going to last more than
| seven years?
| resource_waste wrote:
| I have a super expensive secret on my phone and... I bend the
| knee to Google.
|
| Def can't trust Apple, can't trust Samsung. Google has managed
| to be the best. (Go ahead and @ me some cases that basically
| never hit the wild)
| ForHackernews wrote:
| I can't imagine the threat model that leads you to trust
| Google but not Apple, but you do you: Maybe you're a Google
| hardware engineer and the expensive secret is blueprints for
| the next generation of Google Glass.
| moose44 wrote:
| If only something like GrapheneOS was possible on iPhone. Love
| the system on my Pixel but not a fan of the Android UI and
| functionality.
| DEADMINCE wrote:
| The Android UI allows complete customization, you can even make
| it like iPhone if you want.
| meindnoch wrote:
| This is satire, right?
| SushiHippie wrote:
| https://www.macrumors.com/2022/08/19/copycat-ios-launcher-
| an...
| chasil wrote:
| If you have something like Xposed available, then this is
| possible.
|
| Looking at what GravityBox was able to do, nothing in that
| can be done in a stock ROM without getting root.
| loeg wrote:
| On iPhone, it's called iOS.
| https://security.apple.com/blog/towards-the-next-generation-...
| moose44 wrote:
| This is also satire, right?
| kaba0 wrote:
| I'm not the parent commenter, but not really.
|
| Daniel Micay himself said that iphones are one of the best
| choices from a security perspective, GrapheneOS closing the
| gap. The reason is the close working together of hardware
| and software, which is very seldom done in case of Android
| devices - pixels being the sole exception that care about
| it, that's why they are the only supported device.
|
| Not much point in buying some fancy lock to your door, if
| there is a window open next to it.
|
| Also, ios has a very locked down secure mode for the ultra
| paranoid.
| moose44 wrote:
| The problem with the iOS ecosystem is that it's not safe
| from manufacturer spying? This is the much larger issue
| than 3rd parties. Does lockdown mode prevent this?
| strcat wrote:
| Please read
| https://news.ycombinator.com/item?id=39672701. My actual
| position is that current Pixels with the stock OS and iOS
| have comparable security. iOS has overall better privacy
| including privacy from apps. It's not strictly more
| private and Pixels with stock OS do have areas where they
| do better. AOSP on a Pixel doesn't have the heavily
| integrated Google apps and services which gives it more
| advantages than the stock OS usually has compared to iOS,
| so it's hard to say which has better privacy. A major
| focus for GrapheneOS is addressing the biggest privacy
| weaknesses such as providing Contact Scopes, Storage
| Scopes and a per-app Sensors toggle which not only close
| the gap with iOS in those 3 areas but go significantly
| beyond what it provides. There are still a few areas
| where iOS does better on privacy, but GrapheneOS
| definitely does better overall. Security is a clearer
| picture where it's clearer more secure overall and there
| aren't a lot of areas where it's worse since the Pixel
| stock OS / AOSP starting point has very strong security.
| Suggest that people look through
| https://grapheneos.org/features which explains what we
| provide compared to standard Android 14 QPR2, although
| it's missing a lot of minor features and some recent
| major features.
|
| GrapheneOS gets to focus on the weak points in Android
| and can make a bigger performance and memory usage
| sacrifice to achieve privacy and security. We can also
| add more user-facing features and toggles than either
| Apple or Google is willing to provide. This allows us to
| do many things they can't do. We care a lot about
| preserving app compatibility but we're willing to have
| opt-in features which break some apps, and we're willing
| to break apps with severe memory corruption bugs by
| default with an opt-out toggle to get them working.
| GrapheneOS aims to be nearly as easy to use as the stock
| Pixel OS once we do more work on the out-of-the-box
| experience and bundled apps, but we're willing to have
| more complex privacy and security options available for
| people who can deal with it. We see the starting point of
| AOSP as an already very good base relative to other
| modern operating systems.
| strcat wrote:
| 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 OS have competitive security
| with iOS. GrapheneOS is not closing a gap with iOS on
| security. It is closing a gap on privacy and also
| surpassing it with features like Contact Scopes.
|
| > The reason is the close working together of hardware
| and software, which is very seldom done in case of
| Android devices - pixels being the sole exception that
| care about it, that's why they are the only supported
| device.
|
| AOSP is developed largely with and for Pixels, but that
| is not why they're the only supported devices for
| GrapheneOS. They're the only supported devices because
| they're the only devices meeting the security
| requirements listed at https://grapheneos.org/faq#future-
| devices. If you ignore the differences in APIs between
| iOS and Android while pretending that the iPhone
| supported alternate operating systems, it does not meet
| that full requirements list either. The lack of MTE is a
| simple example.
|
| It's presented as being for the ultra paranoid but what
| it does is mainly reducing huge amounts of attack surface
| created by default enabled Apple services. They're basic
| security measures rather than something super advanced
| and niche. It's all grouped together into one setting
| with some aspects impacting usability a lot without being
| able to get most of the features without that, which was
| their choice, and is what makes it into way more of a
| niche feature than it has to be.
|
| These Apple services/features don't exist for GrapheneOS
| in the first place. People use Signal or the hardened
| Molly fork on GrapheneOS, not iMessage/Facetime, etc.
| Android already takes a more cautious approach to media
| handling in the stock OS. Lockdown mode mainly disables
| the permissive defaults of Apple services/features and
| provides attack surface reduction for Safari. GrapheneOS
| has Vanadium features that are similar such as JIT being
| disabled by default but beyond that those browser parts
| of it there isn't a lot that's applicable.
| kaba0 wrote:
| 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.
| strcat wrote:
| Pixels with the stock OS have comparable security to iPhones
| already. This thread is also about MTE which doesn't exist in
| Apple's hardware yet. The whole point of GrapheneOS is
| providing far better privacy and security than that baseline
| with features like hardened_malloc, Contact Scopes, hardware
| level USB-C port control, etc.
| saagarjha wrote:
| Apple hardware ships with MTE; it's just not enabled.
| snoutie wrote:
| That is informative and unfortunate
| hackerman3309 wrote:
| I'm just glad Rossmann's attempt at killing Graphene failed.
| Also I feel like there's a lesson to be learned there about
| what happens when corpo money and the business mindset that
| Louis has meets open-source.
| snoutie wrote:
| 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
| fddrdplktrew wrote:
| I never installed it because of who the founder is... but
| maybe I'm wrong and it takes someone like this to start
| such a project.
| strcat wrote:
| > but maybe I'm wrong and it takes someone like this to
| start such a project
|
| This is the opposite of helpful. People shouldn't be
| harassing someone with fabricated stories and fake mental
| health diagnosis with no basis. Not clear why you would
| buy into that.
| mewse-hn wrote:
| 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.
| strcat wrote:
| Rossmann targeted me with bullying for a whole year
| before deciding to leak a private chat where I was upset
| with him for supporting harassment including swatting
| attacks. He's a far right bully who is friends with a
| bunch of Kiwi Farms users and even has an official
| verified account there under his real name where he
| happily engages with criminals who harass people. Leaking
| private chats / emails and thoroughly
| misrepresenting/lying about those doesn't somehow put him
| in the right. Suggest you look into him and his extensive
| ties to far right extremism including harassment
| campaigns targeting more people than myself.
| strcat wrote:
| Rossmann's audience noticed that he continued to use
| GrapheneOS on his daily driver driver long after he claimed
| he would stop using it, so even that part wasn't true.
| People noticed he was still clearly using GrapheneOS on his
| daily driver with his Tesla app and other apps. They let us
| know and we looked through the videos they linked us
| through to confirm it. It's true. Recommend reading the
| private emails leaked by Rossmann without believing what he
| says about them. Also recommend familiarizing yourself with
| the multiple years of harassment including swatting attacks
| in April 2023 which Rossmann is connected to and supported.
| He's careful what he says from his official Kiwi Farms
| account but he's still actively friendly with literal
| criminals who harass people to an extreme and tries to
| downplay the site and what they do.
| joemazerino wrote:
| Rossman did nothing of the sort. Watch his video for
| reference.
|
| https://m.youtube.com/watch?v=4To-F6W1NT0&t
|
| What Rossman referred to is easily revealed in this very
| thread from Daniel's comments.
|
| I refuse to use GrapheneOS because of Daniel's behavior. He
| has attacked me personally on this site multiple times.
| strcat wrote:
| This is an extreme bullying/harassment video containing a
| ridiculous level of fabrications and misrepresentations
| clearly aimed at targeting someone legitimately upset
| about swatting attacks and extreme harassment with even
| more harassment. It's also very clearly aimed at
| Rossmann's target audience on Kiwi Farms where he has a
| verified account and actively talks to the person who
| created the Kiwi Farms thread targeting me.
|
| joemazerino has engaged in 6 years of harassment
| targeting me since 2018 on Hacker News. He makes with
| frequent personal insults and spreads fabrications about
| me. He engages in the same vicious bullying pretending
| that I'm insane, making up things about me and
| misrepresenting my statements.
|
| This behavior along with linking harassment/bullying
| content should be absolutely forbidden on this site.
| strcat wrote:
| Thanks for expressing your support for targeting open source
| developers with harassment including swatting attacks and
| fabricated stories about this. Not clear what the relevance is
| supposed to be to ARMv9 MTE.
| joemazerino wrote:
| This kind of response is part of the problem. OP was
| downvoted to oblivion and yet you still feel the need to
| group Rossman and your swatters together.
| strcat wrote:
| You've a highly toxic person who has engaged in many years
| of harassment and spreading fabrications about me on Hacker
| News. It's a terrible look for Hacker News that you haven't
| already been banned. People can look through your comment
| history and see that you've been targeting me with
| harassment and lies since 2018.
|
| Louis Rossmann has an officially verified Kiwi Farms
| account where he's actively friendly with people involved
| in the extreme harassment. He has engaged in a huge amount
| of bullying and fabrications targeting me with the clear
| intent of directing harassment towards me. Rossmann has
| made his far right views quite clear including endorsing
| Ron DeSantis. He has made it clear he is transphobic. He
| has made it clear that he has no real issues with what Kiwi
| Farms does to people despite pretending as if he does while
| making sure not to offend his friends/supporters there who
| he continues actively talking to. The person who made the
| Kiwi Farms thread targeting me actively communicates with
| Rossmann in public for everyone to see. Rossmann is fully
| aware of all this. Rossmann was fully aware that I had been
| repeatedly swatted in a clear attempt to have me killed by
| the police. Trolling and pretending to have no idea what
| was being talked about and downplaying his involved in
| order to leak the chat, portray me as insane and direct
| harassment towards me demonstrates who he is. He made sure
| to leak referring to myself as autistic and talking about
| Kiwi Farms harassment in the emails he leaked.
| wafflemaker wrote:
| 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?
| gray_-_wolf wrote:
| 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.
| eblanshey wrote:
| Most mobile bank websites have 100% functionality already,
| including depositing checks. The bank app isn't needed.
| digging wrote:
| Maybe the real question here though is: Why former?
| gray_-_wolf wrote:
| 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.
| digging wrote:
| Fair enough. I've had many issues on multiple Pixel
| devices with calls never coming through and it can be
| pretty frustrating.
| jstanley wrote:
| 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
| life tolerable, but Google Play doesn't have unfettered access
| to everything on your phone. If you want even more isolation
| you can set up a separate user and run all the Google Play
| stuff in a separate user account, which I did briefly try but
| personally I can't be bothered switching user all the time.
|
| The phone has never crashed. My bank apps work.
|
| I have a Pixel 6a.
| moose44 wrote:
| Second this.
| Pfhortune wrote:
| FWIW, I've used the Web USB installer probably a dozen times
| without issue, so I would definitely recommend that route if
| adb is intimidating. I've done it both ways, but the web
| installer is so easy it feels magical.
|
| As for it not working, were you running a Flatpak/Snap
| version of the browser? Apparently those are problematic with
| Web USB. I personally haven't tried on Linux yet (just Mac
| O's) but now that I've switched to Fedora I might encounter
| the same issue you did.
| jstanley wrote:
| Yes I think it might have been a snap.
| neilv wrote:
| Tip: The GrapheneOS Web installer doesn't work for me with
| the Chromium in Debian Stable.
|
| I always try the Web installer, to see whether it works
| now, but then end up doing the command line method (which
| is also pretty easy, compared to historically how Android
| phone flashing used to work).
| talhah wrote:
| 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.
| jstanley wrote:
| I don't know what Gcam is, but it comes with a camera app.
|
| I've never used Google Pay so I don't know.
| luke-stanley wrote:
| The Google Camera app can be made to work fairly easily.
| Google Pay's NFC payment will not work in a useful way
| because the environment signature differs.
| codethief wrote:
| > The Google Camera app can be made to work fairly
| easily.
|
| In fact, it's as easy as installing it through Play
| Store.
| asdp9iujaspid wrote:
| Google Camera works fine, but is not included out-the-box
|
| Google Pay will not work as GrapheneOS makes no attempt to
| masquerade as a Google-Certified device [0]
|
| [0] https://grapheneos.org/usage#banking-apps
| Suffocate5100 wrote:
| It does not work on the phone, but I was able to use NFC
| payments with Google Wallet through my Pixel Watch.
| nani8ot wrote:
| 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
| strcat wrote:
| > 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 guides now. fwupd usually
| loses the race to connect to the device to the CLI install
| tool but wins the race against Chromium's implementation,
| which is why it impacts web install more. This is likely what
| you experienced before we documented this fwupd bug and got
| them to fix it upstream. The problem is that even though
| fwupd fixed it a while ago, Debian and even the latest Ubuntu
| still have the bug.
| trompetenaccoun wrote:
| 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.
| ysnp wrote:
| (not on the team) I believe the project are open to
| supporting other devices that meet the criteria, or
| collaborating with hardware partners to that effect.
|
| As I understand, the way it works is that the project
| first has to scope out a hardware target that meets their
| security requirements before support can be considered
| and funded for. Just that right now there are no other
| phones that meet the requirements specified in
| https://grapheneos.org/faq#future-devices
|
| If a phone met those requirements and was not made by
| Google, GrapheneOS would consider supporting it. In the
| case that Google didn't meet the requirements but a
| different phone did, GrapheneOS would support that phone
| and not the Pixels.
| blackbear_ wrote:
| As long as the hardware is supported (so, a pixel phone),
| installing is a breeze and it is not any different from a
| normal android to use as a daily driver. I never had any
| trouble whatsoever and my banking apps work fine. AMA :)
| gclawes wrote:
| The only major inconvenience I've heard of is that Google Pay
| won't let you enroll contactless payments via NFC, apparently
| because GrapheneOS isn't approved/certified by Google Play
| SafetyNet.
| strcat wrote:
| Google Pay doesn't allow using a non-Google-certified OS. It
| checks this with the Play Integrity API. It won't be possible
| to spoof in the long term, so we don't pretend to be an
| insecure old device without hardware attestation to trick the
| checks in the short term.
|
| You can use a Pixel Watch or Galaxy Watch paired with
| GrapheneOS and make payments from the Pixel Watch.
| myself248 wrote:
| Super easy. It's been my daily driver and just works. Never
| used banking apps so I can't tell you there.
| freedomben wrote:
| It's pretty easy to install using the web installer. Even the
| "manual" command-line install is really not bad. If you've
| never used adb before there might be some snags, but there's
| tons of places online to get help.
|
| As a daily driver, it's very mature and stable. The only
| downside for me is just a discovery of how much of the Google
| apps I use and how much they improve the stock experience. The
| biggest example for me was the keyboard (including speech to
| text). Thankfully (and something I give credit to Google for as
| they could make this hard or impossible), you can install most
| or all of those apps, including the Pixel Camera app, so you
| don't really have to give up much.
|
| One important thing to note with Graphene is that they
| prioritize _security_ , which is a little different than many
| ROMs in the past. For example, they highly _discourage_ rooting
| due to its security implications, whereas in the past many ROMs
| came with root out of the box.
| digging wrote:
| I'll agree with all these other answers. It's fairly easy to
| set up and I've been using it with no more issues than I would
| expect on stock Android for years. I don't use bank apps
| though, I just log in to their website.
| dtx1 wrote:
| > Is it very inconvenient to use as a daily driver?
|
| No but it is not the most convenient thing either. The Security
| Additions, Sandboxing Setup and a bit of slowness due to the
| hardened memory allocator are more annoying than just using
| plain android and clicking ok for whatever data it wants from
| you. Initial Setup and understanding what makes grapheneos
| different and how to use it's security features takes a bit
| though.
|
| > How often phone just crashes and requires a few days of
| debugging?
|
| Crashes? I haven't had one in my 4 years of usage. At least not
| a systemwide crash. Crashes that require days of debugging are
| in my experience not something that happens because hardware
| and software on pixel devices is well tuned for each other.
|
| > Will my bank app work on it?
|
| Depends on your banking app. Some work without any play
| services, most work with sandboxed playservices, very few do
| not work at all. Best you can do is tell us which bank you use
| and see if another user can confirm it works.
| pledess wrote:
| I guess there's also a chance that a banking app will
| initially work but then fail after a forced update at a very
| inconvenient time. Is there a possibility that some use of
| "integrity signals" (in SafetyNet Attestation API and Play
| Integrity API) will be banned in the EU out of antitrust
| concerns? https://developer.android.com/privacy-and-
| security/safetynet...
| strcat wrote:
| Yes, it's very possible that the EU will regulate this due
| to antitrust concerns and they are actively looking into
| it.
| strcat wrote:
| > The Security Additions, Sandboxing Setup and a bit of
| slowness due to the hardened memory allocator are more
| annoying than just using plain android
|
| You can opt-out of secure app spawning if you deeply care
| about the small latency added to initial cold start app
| spawning time. You can opt-out of hardened_malloc with a per-
| app toggle if you find an app that's incompatible (memory
| corruption bugs caught by it) or which has bad performance
| with it.
|
| There's no noticeable performance impact in regular usage.
| The only thing that was noticeable is the secure spawning
| (exec-based spawning) taking longer for initial app spawning
| time but that's entirely covered up by the animation time on
| current generation devices. There's a toggle for this for
| people who absolutely cannot cope with it, but we strongly
| recommend using secure spawning because many other security
| features depend on each app getting their own initial memory
| instead of being clones from the same template process
| (zygote) with a shared memory layout. It's not only about
| ASLR. It impacts PAC, MTE and any other partially or fully
| probabilistic mitigations.
|
| > Crashes? I haven't had one in my 4 years of usage. At least
| not a systemwide crash. Crashes that require days of
| debugging are in my experience not something that happens
| because hardware and software on pixel devices is well tuned
| for each other.
|
| GrapheneOS has user-facing crash reporting not present in the
| stock OS so users will definitely notice system process
| crashes they wouldn't have otherwise noticed. This helps us
| find issues like the Bluetooth crash the thread we posted was
| about fixing. We make all MTE detected crashes user facing
| since they tend to be serious issues and the crash reports
| tend to be useful for app developers or to us. We don't
| report all crashes by default but rather have a toggle for
| enabling that for the base OS in Settings > Security because
| it's too noisy. For example, sometimes hardware fails to
| fully wake up in the initial second of boot which
| automatically restarts the OS. It ends up reported as a
| kernel crash despite the fact that people wouldn't normally
| notice it. We got flooded with reports about this and had to
| reduce the scope of the user-facing reporting by default with
| opt-in to the rest.
|
| Our features do find memory corruption bugs which were often
| not causing breakage in the stock OS but we believe this
| Bluetooth bug DOES often cause breakage in stock OS. It shows
| the other side of it which is that by finding the bugs, you
| can fix them, and you have fewer bugs remaining. GrapheneOS
| has dozens of fixes for upstream bugs. We try to report the
| security bugs upstream but their handling of non-security bug
| reports is awful so we don't bother for those.
|
| > Depends on your banking app. Some work without any play
| services, most work with sandboxed playservices, very few do
| not work at all. Best you can do is tell us which bank you
| use and see if another user can confirm it works.
|
| At this point, it's nearly just the apps that are
| deliberately trying to prevent using an alternate OS which
| don't work. Apps using Play Integrity API to forbid using an
| alternate OS is nearly anything that doesn't work. Some apps
| also have older implementations of manually detecting an
| alternate OS. For example, a tiny number of apps look at the
| call stack leading to starting their app and purposely crash
| it doesn't match the stock OS which happens with exec-based
| spawning enabled, which we could add a per-app toggle to work
| around but an alternative without more complexity would be
| making it show the same call stack. It's quite silly that
| this is a problem. Play Integrity API is replacing most of
| these custom hacks to detect tampering with apps, hooking
| apps, etc. Play Integrity API COULD allow using GrapheneOS by
| verifying it using hardware attestation but of course
| doesn't. Apps can use hardware attestation themselves to do
| this, but they don't currently do it. We're working on
| convincing at a few major apps to do that. It's covered at
| https://grapheneos.org/articles/attestation-compatibility-
| gu....
| noman-land wrote:
| It's extremely easy to install. You download a couple things
| and copy/paste a terminal command or two.
|
| It's nearly indistinguishable from stock Android. It seriously
| Just Works. You may have to enable sandboxed Google Play
| Services to get some apps but other than that it's basically
| perfect.
| jackwilsdon wrote:
| You don't even need to download anything - if you're using a
| supported browser you can just use the web installer (you can
| even use another Android phone!):
| https://grapheneos.org/install/web
| noman-land wrote:
| Web installer requires Chrome :(.
| logicprog wrote:
| It's extremely easy to install. The hard version of the
| installation is just plugging your phone in Via usb, doing some
| things with the power and volume rocker buttons, and copy
| pasting like two or three terminal commands. The easy version
| is just plugging your phone into your computer and using the
| single click installer button that works in any Chrome browser.
|
| As for how it works, it's been my daily driver OS on my Google
| pixel 6 nearly since the pixel 6 came out, and I've never once
| had it crash on me. Ever. It's never bugged out or needed me to
| debug or fix or maintain it in any way either. Every app I've
| ever tried just works on it too, as if I was using stock
| android, I literally don't even notice the difference honestly.
| Like sometimes I even forget this isn't what my phone came
| with. Personally my banking app, discover, works, but I don't
| know if others would, although I think they probably should
| since it has Google Play services and the bootloader is locked
| once you're done installing.
| heywherelogingo wrote:
| Graphene is great, the problem is pixel phones. We need an
| effort to push other manufacturers to get on board.
| gausswho wrote:
| 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?
| jetbalsa wrote:
| Android Auto is not yet supported in GrapheneOS and that's
| pretty much half the usage of my phone gets on a daily basis
| stevenae wrote:
| Is that up to date? Their site describes support
|
| https://grapheneos.org/features#android-auto
| devit wrote:
| Android Auto support has been added recently and it seems
| to work well.
| pomian wrote:
| Check different cables. I bought a cheap one, didn't work. I
| bought a Google one it worked. But it broke soon. I bought
| another different brand and it works great.
| pomian wrote:
| 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.
| gspencley wrote:
| 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.
| jacooper wrote:
| 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.
| gspencley wrote:
| It's possible that there was something I didn't figure out
| how to configure correctly, but I spent a good chunk of
| time on our vacation mucking with various settings,
| including disabling re-routing location to the OS :/
| VariousPrograms wrote:
| I had the same experience with the Disney parks app not
| working properly at all on Graphene. Otherwise I haven't
| had issues, even with other fitness/map apps that require
| GPS.
| saint_yossarian wrote:
| 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.
| strcat wrote:
| > Is it very challenging to install Graphene OS?
|
| It's very easy to install with the web installer.
|
| https://grapheneos.org/install/web
|
| You can buy a device with it, but nearly anyone can use the web
| installer. It's particularly easy to use from Android, ChromeOS
| and macOS. Windows is a bit trickier since you need to install
| a driver. Desktop Linux requires installing udev rules, and
| some distributions with frozen software versions have a buggy
| service which interferes.
|
| > Need special cables and to know a lot about jailbreaking
| Android devices, or will I be fine just following instructions?
|
| Non-technical people can do it. You only need a browser with
| WebUSB. You don't need any special software.
|
| > Is it very inconvenient to use as a daily driver?
|
| Nearly the same as the stock Pixel OS with nearly as broad app
| compatibility if you use sandboxed Google Play.
|
| > How often phone just crashes and requires a few days of
| debugging?
|
| You likely won't experience significantly more crashes. It has
| user-facing crash reporting not existing in the stock OS so
| you'll notice crashes you wouldn't have known about it. Buggy
| apps with memory corruption may crash until you enable the per-
| app compatibility mode, ESPECIALLY if you opt-in to forcing MTE
| for all user installed apps.
|
| > Will my bank app work on it?
|
| If your bank allows a non-Google-certified OS, which most still
| do. Banks are gradually disallowing using a non-Google-
| certified OS and this essentially needs to be addressing as an
| anti-competition regulation issue. We're working on convincing
| banks to use https://grapheneos.org/articles/attestation-
| compatibility-gu... in the meantime.
| class3shock wrote:
| Very easy and solid as a daily driver. I have a Pixel 6a that
| I've been running it on from when I got it ([?]1.5 years), I've
| never needed to debug anything. My banking apps have worked
| without issue. The only issue I've encountered is one dual
| factor authentication app not working on it.
| hexfish wrote:
| And Netflix can't be installed (at least through the Play
| store) because of restrictions from Netflix' side (I
| suppose). But that's okay, I can just stop my subscription
| through the web interface.
| mepian wrote:
| Do any decent single-board computers implement Arm MTE, e.g. the
| latest Raspberry Pi?
| jeffreygoesto wrote:
| Guess not, the RasPi5 is quad A76 which have v8.2 extensions,
| MTE is v8.5.
| strcat wrote:
| 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.
| ysnp wrote:
| Is Snapdragon hardware present in the current/upcoming
| lineup of Pixel devices such that MTE support is relevant
| to GrapheneOS?
| freedomben wrote:
| > _Android has ported a lot of the Bluetooth code to Rust. This
| is a demonstration of why they need to put more resources into
| porting the rest of the code into Rust._
|
| I like how they snuck that in there :-D
|
| As someone who spent years writing C and C++, but no experience
| with Rust, with this porting from C to Rust, how much refactoring
| is required? That might should be two different questions:
|
| 1. How closely does C translate directly over to Rust? Does Rust
| require some reorganization/refactoring?
|
| 2. How is Google approaching this? Are they trying to closely
| "translate" it as much as possible, or is this an opportunity for
| major rewrite/refactor?
|
| Also very curious if anyone knows, will the Android Bluetooth
| stack ever be usable on a standard Linux distro desktop system?
| meibo wrote:
| It's likely pretty far from a 1:1 port, you'll be
| rearchitecting a lot of what you are writing. It's unavoidable
| due to the way Rust guarantees memory safety.
| tommiegannert wrote:
| I was recently trying to port a PIC microcontroller _simulator_
| from C++ to Rust as an (unfinished) experiment. Because there
| were lots of cyclic references (modules talking to each other
| over "signal busses" with callbacks,) I think I ended up
| fighting Rust more than it helped. It ended up requiring a lot
| of Box (pointers to heap) for things where I could store the
| data inline in C++.
|
| My conclusion is that if you're writing a simple CLI or
| request-response thing, Rust is probably an easy port. More
| generally, if your code structure could work well with arena
| allocations, moving to lifetime-tagging of references isn't a
| big deal.
|
| But if you're writing (admitted ugly) code with cyclic
| references the way a C programmer would :), Rust will feel like
| an uphill battle and is not the place to start. I need to start
| by restructuring the C++ code, moving ownership to a common
| parent. I think that'll make things better. Iteratively
| learning more about Rust, but continuing to work in C++ until
| the code has a better correspondance to Rust.
|
| Edit: forgot the word simulator, and changed RefCell to Box.
| steveklabnik wrote:
| > It ended up requiring a lot of RefCell (pointers to heap)
|
| Just so you know, RefCell does not inherently point to the
| heap. If you put a Box or something inside, sure, but on its
| own, it doesn't allocate.
| tommiegannert wrote:
| Ah, thanks, I changed it to a Box. I confused the two,
| since I had to use them in conjunction.
| steveklabnik wrote:
| It's all good. For what it's worth, I agree with you
| generally that a lot of the C code I see is like,
| "differently shaped" than the Rust, so it's not super
| simple to port directly over.
| wwwigham wrote:
| Stock Pixel may not ship with it on by default for end users, but
| anyone can enable developer options and enable Memory Tagging
| Extensions - either until toggled off, or for a single session if
| you're trying to test a specific app - if you do want the feature
| on.
| evanjrowley wrote:
| For my Pixel 7a, I searched the Developer Options menu three
| times and couldn't find it. Searching for Memory Tagging
| Extensions in Settings says it's there. Is it hidden somewhere?
|
| Edit: Nevermind, I seen it's only for Pixel 8 phones:
| https://news.ycombinator.com/item?id=38125379
| m3drano wrote:
| is for Pixel 8 and above, since those have Tensor G3, which
| is armv9 IIUC.
| Sent1n3l wrote:
| Taken from the projects official Twitter they offer more
| than what is available by said toggle on stock:
|
| They provide a nicer MTE implementation as part of
| hardened_malloc which uses the standard random tags with a
| dedicated free tag but adds dynamic exclusion of previous
| tag and current (or previous) adjacent tags. We also fixed
| Chromium's integration and will improve PartitionAlloc.
|
| They also use it for their browser too using
| PartitionAlloc. Other Chromium-based browsers including
| Chrome don't use MTE since they don't really use the system
| allocators and have PartitionAlloc MTE disabled.
|
| They are also continuing work on integrating more ARMv9
| security features. MTE having the highest impact and being
| the most interesting of these features, but they're
| expanding usage of PAC and BTI. Android uses Clang's type-
| based CFI but not everywhere so BTI is still useful.
| strcat wrote:
| Enabling it via developer options is only the first step. You
| also need to enable it via setprop using ADB in the desired
| mode. The official documentation for using MTE on the stock
| Pixel OS is available at
| https://developer.android.com/ndk/guides/arm-mte. We strongly
| recommend this for app developers. It's a really easy way to
| find heap memory corruption in your apps, but you can use
| stack MTE without building the OS and your app with it.
|
| We provided a user facing crash report system for memory
| corruption detected by MTE. MTE has no false positives. We
| strongly recommend users use the feature we provided for
| copying the crash report to report these bugs to app
| developers. App developers can replicate many of the bugs
| reported this way using either MTE on a Pixel 8 or a smaller
| subset by building their app with HWASan support.
|
| Since many apps have latent memory corruption, we only enable
| it for the base OS, base OS apps and known compatible user
| installed apps by default. Users can opt-in to heap MTE for
| all user installed apps via Settings > Security and can then
| opt-out for apps with memory corruption occurring during
| regular use. Over time, we plan to add more apps like
| Signal/Molly known to be compatible to it into our app
| compatibility database so that it's force enabled for them by
| default without users enabling it in Settings > Security. The
| option to opt-out is only available for apps not known to be
| compatible with it, which is part of dealing with the issue
| of users potentially allowing it after an exploit attempt.
|
| We're trying to convince Google to at least enable
| asynchronous MTE by default for the stock Pixel OS with user
| installed apps excluded from it unless they opt-in to it. The
| memory overhead is 3.125% and asynchronous heap MTE is near 0
| performance overhead. Asymmetric heap MTE provides much
| better security but is more comparable to the overhead of a
| feature like legacy stack smashing protection. Stack MTE adds
| more overhead but SSP could be disabled to partly make up for
| it and deterministic protection of stack spills, return
| value, etc. can be provided through MTE instead since by not
| being tagged they have the 0 tag and everything tagged will
| be a random non-0 tag.
| strcat wrote:
| That's not the same as what's being used on GrapheneOS. It also
| excludes a significant portion of Bluetooth. Enabling support
| for memory tagging in the stock Pixel OS via developer options
| only makes it available for usage but doesn't actually use it.
| You also need to enable heap memory tagging via the Android
| Debug Bridge (ADB) shell via setprop. It provides no value
| through simply being enabled without using it to tag
| allocations. You can fully enable userspace heap MTE for the
| stock OS via the standard allocator implementation (Scudo)
| which is currently not particularly hardened. You can also use
| KASan via the MTE backend using setprop, but that's not
| designed for hardening right now and it's not clear it will
| ever be. There likely needs to be a separate MTE implementation
| for the kernel that's not part of KASan, which we haven't done
| yet for GrapheneOS either so MTE hardening is currently a
| userspace feature.
|
| GrapheneOS uses our own implementation of hardware memory
| tagging for hardened_malloc with stronger security properties.
| In order to enable it by default for the base OS, we had to fix
| or work around various issues including this one. We use MTE in
| asymmetric mode across all cores rather than using asynchronous
| MTE for the main cores. Asymmetric mode is asynchronous for
| writes but synchronous for reads, which blocks exploitation
| properly rather than having a window of opportunity to succeed
| with exploitation. It gets checked on system calls and io_uring
| (another potential source of bypasses) is only available to 2
| core system processes on Android via SELinux restrictions
| (fastbootd which is only used during installation and snapuserd
| used by the core OS after applying updates).
|
| GrapheneOS always uses heap MTE for the base OS and apps known
| to be compatible with it. For user installed apps which are not
| in our compatibility database and which do not mark themselves
| as compatible, we provide a per-app toggle for enable MTE.
| Users can also toggle on using MTE by default for user
| installed apps which may not be compatible and can instead opt-
| out for incompatible apps. In order for this to be usable, we
| had to implement a user-facing crash reporting system. We did
| this in a way that users can easily copy a useful crash report
| to provide developers.
| ignoramous wrote:
| Some background on Sanitizers (ex: kasan) and ARM Memory
| Tagging Extension (mte) by the one of its developers, Andrey
| Konovalov:
|
| https://youtu.be/KmFVPyHyfqQ /
| https://ghostarchive.org/varchive/KmFVPyHyfqQ
|
| https://youtu.be/9wRT2hNwbkA /
| https://ghostarchive.org/varchive/9wRT2hNwbkA
| xvector wrote:
| > _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 disable such a significant security feature for
| negligible performance gain.
| Aurornis wrote:
| I think their accusation that the decision was made to save 3%
| memory usage is too presumptive. They also claim that no other
| OS is shipping with MTE enabled right now. The decision to
| enable is likely more nuanced.
| strcat wrote:
| 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
| the userbase on the latest generation with MTE is quickly
| growing. People on 4th/5th generation Pixels need to move on
| due to them being end-of-life (other than the Pixel 5a, which
| will be soon) and we're encouraging moving to the ones with
| the biggest hardware security improvement since we started.
| We're not making things up.
|
| They could enable it for the whole base OS and apps opting
| into it. They have already fixed nearly all the bugs
| uncovered in regular usage. They did nearly all the work but
| didn't take it over the finish line due to performance and
| memory/cache usage concerns. Their security engineers did
| their job already. They have very talented people working for
| them. Our ability to ship this feature before them is because
| the performance and memory concerns are not significant
| enough to matter to us. We're more than willing to lose
| 3.125% memory/cache and we accept the performance overhead of
| asymmetric MTE which is in the ballpark of a few percent
| overhead in most cases rather than near 0% like asynchronous
| MTE. There are cases where asymmetric MTE has a larger
| overhead than a few percent, but it's not common. Async mode
| is nearly free. MTE may not be as low overhead on future
| Pixels. It depends on them deciding to prioritize MTE
| performance in their future custom CPU design. If they do not
| ship it in production, it's unlikely that they'll prioritize
| the performance. The overhead may increase from 0% for async
| and a few percent for asymm to a far more significant cost.
|
| The performance argument against MTE being deployed in
| production and against supporting MTE at all is the argument
| that's relevant. There is no other significant reason not to
| ship it for the base OS and enable it for all their own apps
| in their manifests. Getting it enabled for the whole app
| ecosystem is a much bigger problem requiring multiple steps:
| 1) broad availability of MTE capable devices for app
| developers, 2) making it opt-out instead of opt-in for a
| future target API level so developers get around a year and a
| half to either opt-out or deal with it, 3) removing the opt-
| out for a future target API level so that developers cannot
| simply opt-out. We know that part is hard. We know that part
| involves documentation, developer relations, concerns about
| giving app developers too much to deal with too quickly, etc.
| It isn't what we expect them to do short term. What we want
| them to do is enabling the near 0 overhead sync MTE for
| Pixels by default, with it used in the base OS and Google
| apps opting into it. They already did most of the work, even
| years earlier via HWAsan testing.
|
| We don't expect them to enable asymmetric MTE or keep track
| of tags to provide more deterministic guarantees as we're
| doing. We understand they don't want to sacrifice 5% overall
| performance, and don't expect them to, but they could provide
| an opt-in for asymmetric mode + better deterministic
| guarantees. Google can could do it for Android 15 if they
| make the decision to do it now. A reasonable prediction is
| that in a couple years Apple ships MTE support in hardware
| with async mode by default and asymm in lockdown mode, and
| then Google does the same. They have a chance to be a leader
| on a hardware security feature far more valuable than the PAC
| feature where iOS is years ahead.
| loeg wrote:
| 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.
| strcat wrote:
| > 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.
| saagarjha wrote:
| 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?
| moonshot5 wrote:
| 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
| the larger OEM ecosystem when complaining about specific
| feature roll outs.
|
| 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.
| strcat wrote:
| > 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.
| DannyBee wrote:
| TL;DR I would not assume they are not using it, or that this is
| about 3.125% memory/cache usage.
|
| Longer answer:
|
| Google folks were responsible for pushing on Hardware MTE in
| the first place - It originally came from the folks who also
| did work on ASAN, syzkaller, etc. They are not in Android, but
| it was done with the help and support of folks in Android.
| That's the Google side, it was obviously a partnership with
| ARM/etc as well.
|
| I was the director for the teams that created/pushed on it, way
| back when - this was years ago at this point because of the
| lead times on a hardware/architecture feature like this.
|
| So i'm very familiar with the tradeoffs.
|
| It is more than just the memory usage or cache. The post is
| correct that it was designed to be able to be enabled/disabled
| dynamically, and needed to have expected perf cost ~0, but the
| main use case at the time was sampling based bug finding.
|
| That is, if you turn MTE on (whether servers, phones, whatever)
| for 1% of the time for your entire fleet, and you have a large
| enough fleet, you will find basically all bugs _very_ quickly.
| You can do this during dogfooding, etc.
|
| Put another way - the goal was to make it possible to use have
| the equivalent of ASAN be flipped on and off when you want it.
|
| Keeping it on all the time as a security mitigation was a
| secondary possibility, and has issues besides memory overhead.
|
| For example, you will suddenly cause tons of user-visible
| crashes. But not even consistently. You will crash on phones
| with MTE, but not without it (which is most of them).
|
| This is probably not the experience you want for a user.
|
| For a developer, you would now have to force everyone to test
| on MTE enabled phones when there are ~1 of them. This is not
| likely to make developers happy.
|
| Are there security exploits it will mitigate? Yes, they will
| crash instead of be exploitable. Are there harmless bugs it
| will catch? Yes.
|
| But keep in mind what i said at the beginning - i would not
| assume they don't use it.
|
| I would instead assume they don't necessarily use it in
| production on all the time.
|
| Anyone who has experience on hardware feature bringup of this
| kind will tell you the fact that they can boot and run the
| system and only when they do this one thing does it crash under
| MTE is actually a very good sign _they do use it_.
|
| Otherwise it would have probably crashed a million times :)
|
| As an aside - It's also not obvious it's the best choice for
| run-time mitigation.
| strcat wrote:
| We didn't propose enabling MTE for apps not opting into it
| any time soon. We proposed enabling it for the base OS by
| default. Pixels are already testing with HWASan and MTE so
| there are few issues found by it in the base OS. Enabling it
| for the base OS and apps opting into it would be a great
| start. Requiring working MTE support for ARMv9 in the CDD is
| entirely doable, and then devs will have devices with it, and
| it can be made into a default for apps at a new target API
| level with opt-out instead of opt-in. It can then be made
| into a mandatory feature at a future target API level.
| Android makes dramatically more aggressive backwards
| incompatible changes via target API levels than detecting
| memory corruption without false positives.
|
| We know they're actively testing HWASan and MTE builds, but
| not with enough real world usage. If they tested it a lot on
| actual devices used by Google employees, they'd have fixed
| this Bluetooth LE audio issue before the release.
| ysnp wrote:
| Thanks for the insight.
|
| >As an aside - It's also not obvious it's the best choice for
| run-time mitigation.
|
| What are some of the current contenders/arguments?
| pjmlp wrote:
| I can hardly wait until mainstream hardware catches up to Solaris
| SPARC in 2015, or previous memory tagged architectures, to
| finally tame all those memory corruption issues, only written by
| bad skilled developers.
| warkdarrior wrote:
| I tried running Solaris SPARC on my phone, but it was dog slow.
| Very secure though!
| pjmlp wrote:
| ....mainstream hardware catches up...
| AnarchismIsCool wrote:
| I'm aware people may downvote the hell out of this, but if they
| do they're the ones writing the bugs: it's not "bad skilled
| developers" it's everyone. Memory corruption is basically a
| language feature of C/C++.
|
| It's best to not perpetuate the belief that it's dumb people
| because very few people think they're dumb and I've seen some
| absolutely amazing coders write some hilarious memory bugs. It
| just comes with the territory of those languages. It's not "if"
| it's "when".
| pjmlp wrote:
| My favourite quote.
|
| "A consequence of this principle is that every occurrence of
| every subscript of every subscripted variable was on every
| occasion checked at run time against both the upper and the
| lower declared bounds of the array. Many years later we asked
| our customers whether they wished us to provide an option to
| switch off these checks in the interests of efficiency on
| production runs. Unanimously, they urged us not to--they
| already knew how frequently subscript errors occur on
| production runs where failure to detect them could be
| disastrous. I note with fear and horror that even in 1980
| language designers and users have not learned this lesson. In
| any respectable branch of engineering, failure to observe
| such elementary precautions would have long been against the
| law."
|
| -- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
|
| After 50 years of the Morris worm, only C Machines can fix
| the non existence of the mythical high skilled developer, and
| as Hoare predicted it is finally becoming a liability not to
| care about security.
| ngneer wrote:
| Great quote. Nice to have memory tagging to help with the
| debug process these days. Not surprising to see these
| mistakes being made about 50 years later, as the
| fundamentals have not changed. Doing the same thing and
| expecting different results is, well, you know...
| brcmthrowaway wrote:
| How does MTE compare to CHERI?
| saagarjha wrote:
| Much lower overhead, currently shipping, able to detect some
| forms of heap corruption but not nearly as reliably as CHERI.
| No protection on tags and small (2^4) space for them.
| gchadwick wrote:
| 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 cause anything bad
| to happen (imagine a typical buffer overflow, it may well be
| the words immediately beyond the end of the buffer aren't being
| but to any other purpose so using them actually works). MTE
| will detect these and they can be investigated and patched
| before they can get turned into a weaponised exploit.
| brcmthrowaway wrote:
| Google should use CHERI
| mynameisnoone wrote:
| This is 2024. We need formally-verified operating systems,
| applications, and tools in the spirit of seL4 but going beyond it
| in rigor. Cobbling together lightly tested, over-engineered,
| heaving codebase systems with fragile, dangerous languages in
| this day and age is asking for users dying when foreign actors
| hack them, annoying bugs for many, and attack surface for malware
| and hacking generally.
|
| On top of that, clean and unified UX and usable features must be
| provided or the engineering is all for naught.
| saagarjha wrote:
| I look forward to seeing your implementation of this :)
___________________________________________________________________
(page generated 2024-03-11 23:00 UTC)