Thread

GrapheneOS – When an app is slow

86 points · 64 comments · speckx

Loading the complete thread in the background. This saved snapshot is available now. Refresh

perching_aix · 1790622062 · focus · HN ↗
If you have two apps, both maps...
> The reason behind it is the hardened memory allocator, which seems to create a significant overhead for Osmand. That might be because scrolling a map requires constant loading and discarding of data.
... is this really the right hunch, over e.g. the OpenStreetMaps app lacking in discipline with its heap allocations?
1. himata4113 · 1790622580 · focus · HN ↗
  Seems unlikely, it's java so this is likely related to loading large amounts of objects and having the GC thrashing.
  1. RedComet · 1790626381 · focus · HN ↗
    The core is C++ afaik.
    grapheneos · 1790802500 · focus · HN ↗
    OsmAnd has a large legacy C++ codebase with a lot of memory corruption bugs. Many memory corruption bugs have been found and reported by GrapheneOS users. It isn't yet clear if the performance issues the OpenGL renderer has with hardened_malloc are caused by it making too many allocations or actual bugs.
    The hardened_malloc configuration used by GrapheneOS is very security-oriented including using a quarantine for freed slab allocations and it could provide a toggle to use a more performance-oriented configuration for an app instead of only being able to use the default allocator instead.
  2. someonebaggy · 1790631687 · focus · HN ↗
    C++ memory allocator choice probably wouldn't affect Java code, which has its own heap algorithms.
    cnrcode · 1790636048 · focus · HN ↗
    [dead]
    grapheneos · 1790676553 · focus · HN ↗
    The hardened allocator doesn't wrap malloc but rather is the default malloc implementation on GrapheneOS with a per-app opt-out toggle. It makes no substantial difference for overall OS performance but there are definitely apps where it matters. OsmAnd works fine for most users without disabling it though.
2. grapheneos · 1790801973 · focus · HN ↗
  It's very likely caused by a set of bugs in the app rather than simply inefficient patterns. Users regularly report hardened_malloc detecting memory corruption bugs in OsmAnd.
pjmlp · 1790622198 · focus · HN ↗
Maybe the actual solution is to improve, replace the application.
1. mohamedkoubaa · 1790622413 · focus · HN ↗
  There needs to be a wall of shame for apps that abuse hardware owned by users
  1. yjftsjthsd-h · 1790623134 · focus · HN ↗
    How's it abusing anything? It's an Android app that works fine with the default Android memory allocator.
    perching_aix · 1790624342 · focus · HN ↗
    That doesn't necessarily mean it isn't being abusive, just that said allocator tolerates it okay.
    pjmlp · 1790625092 · focus · HN ↗
    The AOSP memory allocator is seldom the one used by OEMs.
    rpdillon · 1790627185 · focus · HN ↗
    Really? They're not using Scudo? The hardened_malloc used in GrapheneOS has a bunch of performance issues that were trade-offs against security. Every other major android distribution uses scudo as far as I know. Which OEMs are you thinking of?
    Edit: Did some research after writing this? It appears that Samsung may be still using jemalloc, albeit a newer version than the one from the Android 11 days.
    grapheneos · 1790676709 · focus · HN ↗
    No, it does not have "a bunch of performance issues". It has carefully considered performance vs. security compromises which are largely configurable. GrapheneOS uses hardened_malloc in a very security-oriented configuration and has the option to disable it per-app if there's ever a compatibility or performance issue. GrapheneOS could also offer another toggle for setting it to a performance mode where it isn't significantly slower than Scudo either via dynamic configuration or a 2nd build of hardened_malloc with a lighter configuration. Most overhead is from slab allocation quarantines which are optional.
    rpdillon · 1790692594 · focus · HN ↗
    Yikes, didn't mean to trigger any defensiveness. Can't edit my comment, but mentally replace "bunch of performance issues" with what you said: "performance vs. security compromises".
2. izacus · 1790622685 · focus · HN ↗
  Or maybe there's a reason why the mainline Android OEMs don't ship that allocator by default.
  1. Groxx · 1790624991 · focus · HN ↗
    The fairly obvious answer here is "OEMs don't care about security because very few people will pay for it, either with $ or time". Benchmaxxing sells better.
    izacus · 1790626398 · focus · HN ↗
    That's trivially provable as false.
    nvme0n1p1 · 1790626653 · focus · HN ↗
    If so, I'd love to know which OEM you're thinking of who ships an Android distro more secure than GrapheneOS.
    izacus · 1790627267 · focus · HN ↗
    Let's first start with y'all providing any proof that it was "benchmaxxing" that causes OEMs not to ship hardened allocators (and not - for example - breaking compatibility with users' software).
    And then we can move the goalposts to "more secure distro with GrapheneOS" which isn't part of the conversation until you dragged it out.
    nvme0n1p1 · 1790630370 · focus · HN ↗
    If you're expecting some leaked internal document that says "priorities: 1. benchmarks, 2. security", no, that probably doesn't exist. But their priorities are revealed by their actions.
    GrapheneOS typically ships security updates within a day. But most of Samsung's phones get quarterly security updates[1]. There will never be a primary source with a Samsung insider saying "we're fine with our customers being vulnerable to widely exploited security bugs for 89 days, in order to save our massive corporation a few thousand dollars a month." But their priorities are revealed by their actions.
    If the statements "OEMs don't care about security" is trivially proven false, as you said, then you should be able to prove it trivially by naming even just a single OEM whose update cadence matches GrapheneOS's.
    [1]: <a href="https://security.samsungmobile.com/workScope.smsb" rel="nofollow">https://security.samsungmobile.com/workScope.smsb
    Groxx · 1790630893 · focus · HN ↗
    Also look at their advertising. Endless "X% faster" mentions that often get significant visual space, but when was the last time you saw "security updates 7 days earlier" or "tagged memory for better safety"? Even a single mention of "security" on a phone's manufacturer page is uncommon, and that's usually just mentioning a normal Android feature, or something like Knox or Secure Folder and not "we made choices that make a common class of attacks much more difficult or impossible".
    The numbers aren't zero, certainly. But they are incredibly obviously given wholly different levels of attention.
    izacus · 1790749369 · focus · HN ↗
    There isn't a single phone and OS release that wouldn't have a security improvements section: <a href="https://blog.google/products-and-platforms/platforms/android/android-17-features/" rel="nofollow">https://blog.google/products-and-platforms/platforms/android...
    (I'll let you find the others yourself.)
    How did you think Pixels got features GrapheneOS needs if the OEM wouldn't care about adding the Titan chip, modem APIs and all the other security features that are featured on pretty much every launch doc?
    Cut the crap already.
    Groxx · 1790888195 · focus · HN ↗
    Then let's just take a random flagship device: <a href="https://www.samsung.com/us/smartphones/galaxy-s26/" rel="nofollow">https://www.samsung.com/us/smartphones/galaxy-s26/
    The only "secure" stuff I see in there is for local AI stuff, encrypted folders, and securely managing other devices. Nothing at all about hardware security or updates or anything that Google has been adding to Android (which imo they're fair to claim! but nearly none do).
    iPhones are similar: <a href="https://www.apple.com/iphone-18-pro/" rel="nofollow">https://www.apple.com/iphone-18-pro/ they have a small card to see Apple's general privacy policy near the bottom, but other mentions are stuff on the level of "it supports WiFi with passwords".
    While there's tons about AI, cameras, and speed. Because those sell better.
    Which is far beyond "a trend" and approaching "a truism" for phone sales pages. I challenge you to show even a single large-market-share phone sales page that makes a device security claim (niche ones do! but they're niche). The very first one I visited demonstrated my point just fine, as did the second.
    Pixels actually do make some claims ("7 years of updates", Titan chip, etc <a href="https://store.google.com/product/pixel_11_pro?hl=en-US" rel="nofollow">https://store.google.com/product/pixel_11_pro?hl=en-US) and Graphene routinely holds them up as the sole manufacturer doing a good job (now hopefully two manufacturers, for at least some products).
    nvme0n1p1 · 1790889961 · focus · HN ↗
    The android blog isn't relevant here.
    OEM = original equipment manufacturer
    equipment = the phone you physically hold in your hand
    The OS is software, not hardware. The OS vendor is not the OEM.
    Yes, Android does a lot of security work. No, it doesn't automatically mean Samsung cares about security, just because one of Samsung's many dependencies cares about security.
    pessimizer · 1790633760 · focus · HN ↗
    > Let's first start with y'all providing any proof
    Your trivially proving things can't involve asking other people to prove the opposite of things. You've instantly backed down.
    > And then we can move the goalposts
    Why? You haven't done anything except ask others to do things. You've moved the goalposts from trivially falsifiable, and started begging.
    izacus · 1790749224 · focus · HN ↗
    I'm not going to play a game where you make up false shit and I do the work of disproving it while you move the goalposts with new false shit.
  2. pjmlp · 1790625004 · focus · HN ↗
    Because they cut costs on hardware and not all ship MTE enabled ARMs.
  3. palata · 1790626913 · focus · HN ↗
    Maybe... legacy?
  4. grapheneos · 1790676848 · focus · HN ↗
    The hardened_malloc project has performance vs. security configuration. It's used in a very security-oriented configuration in GrapheneOS. GrapheneOS could offer a performance vs. security toggle for this but hasn't yet included one since there are rarely apps with any noticeable performance difference. Android apps are mostly written in Java/Kotlin where it makes no difference. There are often specific uses of optimized C, C++ or Rust code where it makes little difference. It's rare for an app to be heavily impacted by malloc performance as if it's a malloc microbenchmark, and even in that case the overhead is typically quite reasonable. OsmAnd is doing something very strange in a certain configuration.
negative_zero · 1790623161 · focus · HN ↗
Odd. Google Pixel 7 with GrapheneOS here. OsmAnd works perfectly fine for me without disabling any exploit protection options.
1. BlackRabbit1 · 1790626413 · focus · HN ↗
  CoMaps behaves very very weirdly on GrapheneOS. Same with OrganicMaps.
  Osmand and GMaps are working fine.
  Waze is almost melting the poor thing. Beside of that working fine.
  1. ThePowerOfFuet · 1790626988 · focus · HN ↗
    I use Comaps daily on GrapheneOS on a Pixel 8 Pro and it works great.
  2. broodbucket · 1790627024 · focus · HN ↗
    Waze works perfectly fine for me
    DuncanCoffee · 1790627391 · focus · HN ↗
    Anyone writing about apps compatibility should specify if it's with or without the play services
    DaSHacka · 1790627528 · focus · HN ↗
    Can you even run Waze/GMaps without Play services?
    worldsavior · 1790629920 · focus · HN ↗
    Yes.
    Shared404 · 1790631446 · focus · HN ↗
    For more precision:
    Waze is fairly easy to run without play services. GMaps I haven't yet found a way to run, but also haven't looked in quite some time.
    grapheneos · 1790677318 · focus · HN ↗
    Google Maps used to work without it but recently gained a hard dependency on Play services. We could add more shims to make more apps work without it installed but that hasn't been a focus yet.
    Shared404 · 1790743054 · focus · HN ↗
    Makes sense. Any idea if there's any interest in a shim to get notifications working sans Play services?
    I haven't looked at anything shim related in quite a while and am not super familiar with the notification stack for Android, so if that's a stupid question I apologize.
    DaSHacka · 1790688407 · focus · HN ↗
    Neat, every day I inch closer to not needing Play Services anymore.
    <a href="https://plexus.techlore.tech/apps?q=waze" rel="nofollow">https://plexus.techlore.tech/apps?q=waze
    Nux · 1790636881 · focus · HN ↗
    Waze and Here Maps work well.
  3. subscribed · 1790630428 · focus · HN ↗
    Osmand and OrganicMaps work flawlessly for me. Waze on 6 (not pro), works better than on my 9 Pro.
  4. pizzaiolo · 1790632680 · focus · HN ↗
    Weirdly how? CoMaps seemingly works fine out of the box on my device
  5. gunalx · 1790636483 · focus · HN ↗
    Have had no noticable problems with organic maps.
  6. methuselah_in · 1790663928 · focus · HN ↗
    comaps and organic maps shares some of the same codebase right?
    archturtle · 1790684526 · focus · HN ↗
    AFAIK CoMaps is a fork of OrganicMaps after OrganicMaps added some sort of ads or sponsoring. They both use OSM
  7. grapheneos · 1790677029 · focus · HN ↗
    CoMaps and Waze definitely work well on GrapheneOS.
2. Self-Perfection · 1790634493 · focus · HN ↗
  And yet problems exist. Live Updates are not rendered if both OsmAnd V2 rendering and hardened memory allocator are enabled: <a href="https://github.com/osmandapp/OsmAnd/issues/20190" rel="nofollow">https://github.com/osmandapp/OsmAnd/issues/20190
  1. [deleted] · 1790801015 · focus · HN ↗
    [deleted]
  2. grapheneos · 1790801820 · focus · HN ↗
    Those are memory corruption bugs which are potentially exploitable vulnerabilities. There are no false positives for the security protections in hardened_malloc including the hardware memory tagging (MTE) integration. It only detects invalid memory corruptions via use-after-free or out-of-bounds accesses. Due to a relatively high number of apps having invalid memory accesses during regular use, we don't enable MTE for all user installed apps yet. We always use MTE for the kernel and userspace code in the base OS but it's opt-in for most user installed apps via a global toggle to enable it by default and a per-app toggle mainly intended for opting out for incompatible apps.
    OsmAnd has a massive amount of legacy C++ code which hasn't been heavily tested with HWASan and MTE. It has a history of having many memory corruption bugs discovered and reported by GrapheneOS users. That's the exploit protections in GrapheneOS working as intended and it's why there are per-app compatibility toggles to work around apps which can't be used due to memory corruption during regular use. It would be better if apps had higher quality native code and didn't need us to provide compatibility toggles but that's the way things are. It's much worse on desktop operating systems.
Groxx · 1790624887 · focus · HN ↗
[delayed]
1. WalterGR · 1790625891 · focus · HN ↗
  [delayed]
  1. Groxx · 1790630612 · focus · HN ↗
    [delayed]
2. grapheneos · 1790676947 · focus · HN ↗
  It ends up acting as a malloc microbenchmark in certain configurations. It appears that it only happens when using the OpenGL renderer. GrapheneOS can provide a performance vs. security toggle for hardened_malloc for these rare cases but it hasn't come up much.
hadi77ir · 1790626692 · focus · HN ↗
I wonder if a website using leaflet.js has better or worse performance in the said case. If it does better, then maybe the problem is on OsmAnd's side?
1. speedstyle · 1790674341 · focus · HN ↗
  Leaflet is (generally) for streaming image tiles, OsmAnd renders a list of features in realtime. But yes, it could do so more efficiently
RKearney · 1790629672 · focus · HN ↗
"Before installing, please turn off all anti-virus and firewall software."
1. grapheneos · 1790676418 · focus · HN ↗
  The feature protects the app from exploits and doesn't provide any additional security for the OS from the app. It's worth noting most users are having no issues running OsmAnd with hardened_malloc.
hajjamixcv2012 · 1790631785 · focus · HN ↗
[dead]
aucisson_masque · 1790632068 · focus · HN ↗
What is the point of this hardening feature if you got to disable it ?
You can tweak Android as much as you want, the OS was not made to be private nor secure. App developers will never check if it breaks the grapheneos memory allocating feature (amongst others) so by default you disable it.
Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.
1. progval · 1790632654 · focus · HN ↗
  It's meant to protect apps against their own bugs. It's an improvement to be enabled by default and disabled for the few apps where it's an issue.
2. epihelix · 1790636715 · focus · HN ↗
  > Anyway it also requires the app to be able to even run on a rom that doesn’t respect play integrity.
  ?? GrapheneOS does respect horrid play integrity (it provides basic integrity only).
  Not that this has any bearing on how an app runs performance-wise.
  1. aucisson_masque · 1790669288 · focus · HN ↗
    Before looking at how an app run “performance wise”, you got to be able to run it. That’s my point.
    Basic play integrity doesn’t mean much, more and more applications are requiring full play service integrity.
    grapheneos · 1790675904 · focus · HN ↗
    Very few apps require Play Integrity levels and a growing number of those are explicitly permitting GrapheneOS.
    aucisson_masque · 1790891787 · focus · HN ↗
    That’s not the trend I’m seeing with my pixel 9. More and more apps require it.
    You just need one app, that you really like and that doesn’t run on grapheneos to make a user leave.
3. grapheneos · 1790676350 · focus · HN ↗
  > What is the point of this hardening feature if you got to disable it ?
  It doesn't have to be disabled. Most users are saying OsmAnd runs fine for them with the default of hardened_malloc being enabled. There was no need to disable the other hardening features. A subset of users are experiencing slow performance in the OpenGL rendering mode with hardened_malloc enabled. It's likely due to the implementation in the app doing something quite inefficient which hasn't yet been identified. The hardened_malloc configuration in GrapheneOS is heavily oriented to security and has more overhead than the lite configuration. We could offer a performance vs. security mode for it but it usually makes no major difference and has a toggle for any case it does.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.