9 ms·

GrapheneOS finds Bluetooth memory corruption via ARM MTE

328 points by gaul 3y ago

dtx1 3y ago
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?
- master-lincoln 3y ago
  [flagged]
- Sytten 3y ago
  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 3y ago
    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 3y ago
      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.
      - strcat 3y ago
        Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.
    - chasil 3y ago
      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 3y ago
        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.
    - strcat 3y ago
      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 https://grapheneos.org/releases and https://grapheneos.org/faq 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 3y ago
    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 https://grapheneos.org/releases and https://grapheneos.org/faq 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 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 3y ago
      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.
      - 3y ago
- perlclutcher 3y ago
  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/2261 https://github.com/uBlockOrigin/uBlock-issues/discussions/22... [1]: https://github.com/VR-25/acc https://github.com/VR-25/acc
  - strcat 3y ago
    > 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 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 3y ago
  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 3y ago
    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+Battery+Replacement/166180 https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem... That's not "swiss knife" replacement.
    - wafflemaker 3y ago
      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
      - strcat 3y ago
        > 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 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.
- IshKebab 3y ago
  Well, maybe. But in this case I think the MTE work is in AOSP and they just turned it on.
  - strcat 3y ago
    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 3y ago
  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 3y ago
    > 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 3y ago
      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 3y ago
      I don't know how they do it, but some of these cases keep the phone at below 100%.
    - worewood 3y ago
      My S20 has an option to limit charge to 85%. It's already a reality.
- Tijdreiziger 3y ago
  They seem to have long-standing problems with emergency services, though. https://www.reddit.com/r/GooglePixel/search/?q=emergency https://www.reddit.com/r/GooglePixel/search/?q=emergency
  - izacus 3y ago
    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_iphone_cant_call_911/ https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone... VoLTE in general is quite the trash fire.
- nelblu 3y ago
  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/ https://calyxos.org/news/2024/03/05/fp5/
  - dtx1 3y ago
    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.
    - deleted 3y ago
      [deleted]
  - strcat 3y ago
    GrapheneOS and CalyxOS are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements: https://grapheneos.org/features 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 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 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-based-operating-system/ https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
  - acqbu 3y ago
    CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.
- strcat 3y ago
  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 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 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 3y ago
    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 3y ago
  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 3y ago
    Are you telling me my battery is going to last more than seven years?
- resource_waste 3y ago
  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 3y ago
    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.
    - resource_waste 3y ago
      Buddy, 1000+ people got their iPhones cracked by pegasus, at least 1 person was killed and bezos had his noods leaked. Yeah google does a better job.
      - ForHackernews 3y ago
        I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models. Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
        resource_waste 3y ago
        Yes, my super expensive secret is way more valuable than getting ads about my hemorrhoids.
        ForHackernews 3y ago
        You know they have secure drives, right? I wouldn't carry anything I really cared about around on my phone. ... oh this is some cryptocurrency thing, isn't it?
moose44 3y ago
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.
- deleted 3y ago
  [deleted]
- DEADMINCE 3y ago
  The Android UI allows complete customization, you can even make it like iPhone if you want.
  - meindnoch 3y ago
    This is satire, right?
    - SushiHippie 3y ago
      https://www.macrumors.com/2022/08/19/copycat-ios-launcher-android-50-million-downloads/ https://www.macrumors.com/2022/08/19/copycat-ios-launcher-an...
  - chasil 3y ago
    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 3y ago
  On iPhone, it's called iOS. https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-...
  - deleted 3y ago
    [deleted]
  - moose44 3y ago
snoutie 3y ago
[flagged]
- deleted 3y ago
  [deleted]
- hackerman3309 3y ago
  [flagged]
  - snoutie 3y ago
    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
    - frickinLasers 3y ago
      [flagged]
      - strcat 3y ago
        [flagged]
        frickinLasers 3y ago
        [flagged]
    - fddrdplktrew 3y ago
      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.
      - deleted 3y ago
wafflemaker 3y ago
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?
- digging 3y ago
  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.
- gray_-_wolf 3y ago
  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 3y ago
    Most mobile bank websites have 100% functionality already, including depositing checks. The bank app isn't needed.
  - digging 3y ago
    Maybe the real question here though is: Why former?
    - gray_-_wolf 3y ago
      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.
      - 3y ago
mepian 3y ago
Do any decent single-board computers implement Arm MTE, e.g. the latest Raspberry Pi?
- jeffreygoesto 3y ago
  Guess not, the RasPi5 is quad A76 which have v8.2 extensions, MTE is v8.5.
  - strcat 3y ago
    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 3y ago
      Is Snapdragon hardware present in the current/upcoming lineup of Pixel devices such that MTE support is relevant to GrapheneOS?
      - transpute 3y ago
        Google Pixel 6/7/8+ silicon is based on Samsung, https://www.digitaltrends.com/mobile/google-pixel-8-tensor-g3-chip-good-or-bad-explained/ https://www.digitaltrends.com/mobile/google-pixel-8-tensor-g...
      - strcat 3y ago
        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.
freedomben 3y ago
> 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?
- deleted 3y ago
  [deleted]
- meibo 3y ago
  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 3y ago
  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.
wwwigham 3y ago
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 3y ago
  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 https://news.ycombinator.com/item?id=38125379
  - m3drano 3y ago
    is for Pixel 8 and above, since those have Tensor G3, which is armv9 IIUC.
    - Sent1n3l 3y ago
      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.
  - deleted 3y ago
    [deleted]
  - strcat 3y ago
xvector 3y ago
> 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 3y ago
  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 3y ago
    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.
pjmlp 3y ago
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 3y ago
  I tried running Solaris SPARC on my phone, but it was dog slow. Very secure though!
  - pjmlp 3y ago
    ....mainstream hardware catches up...
- AnarchismIsCool 3y ago
  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 3y ago
    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.
KingOfLechia 3y ago
[dead]
Donberry 3y ago
[dead]
brcmthrowaway 3y ago
How does MTE compare to CHERI?
- saagarjha 3y ago
  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.
  - strcat 3y ago
    MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it. In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region. In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
    - saagarjha 3y ago
      None of what you said is wrong but the point I was making largely centered around tags being architecturally visible, which is quite different from how CHERI operates.
mynameisnoone 3y ago
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 3y ago
  I look forward to seeing your implementation of this :)
- fsflover 3y ago
  > We need formally-verified operating systems Compartmentalization is a far stronger security measure according to experience. See: Qubes OS.
  - tucnak 3y ago
    Intel only...

328 points by gaul 3y ago

dtx1 3y ago

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?

master-lincoln 3y ago
[flagged]
Sytten 3y ago
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 3y ago
  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 3y ago
    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.
    - strcat 3y ago
      Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.
  - chasil 3y ago
    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 3y ago
      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.
  - strcat 3y ago
    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 https://grapheneos.org/releases and https://grapheneos.org/faq 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 3y ago
  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 https://grapheneos.org/releases and https://grapheneos.org/faq 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 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 3y ago
    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.
    - 3y ago
perlclutcher 3y ago
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/2261 https://github.com/uBlockOrigin/uBlock-issues/discussions/22... [1]: https://github.com/VR-25/acc https://github.com/VR-25/acc
- strcat 3y ago
  > 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 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 3y ago
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 3y ago
  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+Battery+Replacement/166180 https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem... That's not "swiss knife" replacement.
  - wafflemaker 3y ago
    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
    - strcat 3y ago
      > 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 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.
IshKebab 3y ago
Well, maybe. But in this case I think the MTE work is in AOSP and they just turned it on.
- strcat 3y ago
  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 3y ago
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 3y ago
  > 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 3y ago
    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 3y ago
    I don't know how they do it, but some of these cases keep the phone at below 100%.
  - worewood 3y ago
    My S20 has an option to limit charge to 85%. It's already a reality.
Tijdreiziger 3y ago
They seem to have long-standing problems with emergency services, though. https://www.reddit.com/r/GooglePixel/search/?q=emergency https://www.reddit.com/r/GooglePixel/search/?q=emergency
- izacus 3y ago
  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_iphone_cant_call_911/ https://www.reddit.com/r/iphone/comments/ynuu6c/newer_iphone... VoLTE in general is quite the trash fire.
nelblu 3y ago
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/ https://calyxos.org/news/2024/03/05/fp5/
- dtx1 3y ago
  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.
  - deleted 3y ago
    [deleted]
- strcat 3y ago
  GrapheneOS and CalyxOS are very different. GrapheneOS is a hardened OS with substantial privacy/security improvements: https://grapheneos.org/features 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 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 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-based-operating-system/ https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
- acqbu 3y ago
  CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.
strcat 3y ago
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 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 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 3y ago
  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 3y ago
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 3y ago
  Are you telling me my battery is going to last more than seven years?
resource_waste 3y ago
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 3y ago
  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.
  - resource_waste 3y ago
    Buddy, 1000+ people got their iPhones cracked by pegasus, at least 1 person was killed and bezos had his noods leaked. Yeah google does a better job.
    - ForHackernews 3y ago
      I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models. Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
      - resource_waste 3y ago
        Yes, my super expensive secret is way more valuable than getting ads about my hemorrhoids.
        ForHackernews 3y ago
        You know they have secure drives, right? I wouldn't carry anything I really cared about around on my phone. ... oh this is some cryptocurrency thing, isn't it?

moose44 3y ago

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.

deleted 3y ago
[deleted]
DEADMINCE 3y ago
The Android UI allows complete customization, you can even make it like iPhone if you want.
- meindnoch 3y ago
  This is satire, right?
  - SushiHippie 3y ago
    https://www.macrumors.com/2022/08/19/copycat-ios-launcher-android-50-million-downloads/ https://www.macrumors.com/2022/08/19/copycat-ios-launcher-an...
- chasil 3y ago
  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 3y ago
On iPhone, it's called iOS. https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-...
- deleted 3y ago
  [deleted]
- moose44 3y ago

snoutie 3y ago

[flagged]

deleted 3y ago
[deleted]
hackerman3309 3y ago
[flagged]
- snoutie 3y ago
  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
  - frickinLasers 3y ago
    [flagged]
    - strcat 3y ago
      [flagged]
      - frickinLasers 3y ago
        [flagged]
  - fddrdplktrew 3y ago
    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.
    - deleted 3y ago

wafflemaker 3y ago

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?

digging 3y ago
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.
gray_-_wolf 3y ago
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 3y ago
  Most mobile bank websites have 100% functionality already, including depositing checks. The bank app isn't needed.
- digging 3y ago
  Maybe the real question here though is: Why former?
  - gray_-_wolf 3y ago
    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.
    - 3y ago

mepian 3y ago

Do any decent single-board computers implement Arm MTE, e.g. the latest Raspberry Pi?

jeffreygoesto 3y ago
Guess not, the RasPi5 is quad A76 which have v8.2 extensions, MTE is v8.5.
- strcat 3y ago
  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 3y ago
    Is Snapdragon hardware present in the current/upcoming lineup of Pixel devices such that MTE support is relevant to GrapheneOS?
    - transpute 3y ago
      Google Pixel 6/7/8+ silicon is based on Samsung, https://www.digitaltrends.com/mobile/google-pixel-8-tensor-g3-chip-good-or-bad-explained/ https://www.digitaltrends.com/mobile/google-pixel-8-tensor-g...
    - strcat 3y ago
      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.

freedomben 3y ago

> 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?

deleted 3y ago
[deleted]
meibo 3y ago
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 3y ago
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.

wwwigham 3y ago

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 3y ago
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 https://news.ycombinator.com/item?id=38125379
- m3drano 3y ago
  is for Pixel 8 and above, since those have Tensor G3, which is armv9 IIUC.
  - Sent1n3l 3y ago
    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.
- deleted 3y ago
  [deleted]
- strcat 3y ago

xvector 3y ago

> 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 3y ago
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 3y ago
  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.

pjmlp 3y ago

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 3y ago
I tried running Solaris SPARC on my phone, but it was dog slow. Very secure though!
- pjmlp 3y ago
  ....mainstream hardware catches up...
AnarchismIsCool 3y ago
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 3y ago
  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.

KingOfLechia 3y ago

[dead]

Donberry 3y ago

[dead]

brcmthrowaway 3y ago

How does MTE compare to CHERI?

saagarjha 3y ago
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.
- strcat 3y ago
  MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it. In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region. In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
  - saagarjha 3y ago
    None of what you said is wrong but the point I was making largely centered around tags being architecturally visible, which is quite different from how CHERI operates.

mynameisnoone 3y ago

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 3y ago
I look forward to seeing your implementation of this :)
fsflover 3y ago
> We need formally-verified operating systems Compartmentalization is a far stronger security measure according to experience. See: Qubes OS.
- tucnak 3y ago
  Intel only...