GrapheneOS – When an app is slow
Disabling GrapheneOS's hardened memory allocator fixes severe performance slowdowns in the OsmAnd map app caused by native heap allocation overhead.
summary is enough The article offers a simple toggle fix, but the comment thread provides valuable technical context from the GrapheneOS maintainer about memory allocator overhead.
summary
An author noticed that the OsmAnd navigation app ran sluggishly on GrapheneOS and traced the issue to the OS's hardened memory allocator. Disabling the exploit protection for hardened memory on that specific app restored normal performance. Commenters and the GrapheneOS maintainer explained that OsmAnd's legacy C++ rendering engine triggers heavy overhead and catches memory corruption bugs under the security-focused allocator.
key points
- GrapheneOS's strict hardened memory allocator introduces significant overhead for apps with intense native heap allocation patterns like OsmAnd's OpenGL renderer.
- Users can resolve performance issues on a per-app basis by disabling the hardened memory allocator under the app's exploit protection settings.
- GrapheneOS maintainers note that OsmAnd's legacy C++ codebase frequently triggers security quarantines due to underlying memory management quirks.
who should read it
GrapheneOS users experiencing performance degradation and developers interested in memory allocator security overhead.
discussion mixed
consensus
Commenters confirm the performance hit on OsmAnd with hardened memory enabled, while debating whether the issue stems from the allocator's strictness or OsmAnd's legacy codebase.
pushback
A few users report running OsmAnd smoothly with default settings, suggesting the performance penalty only manifests under specific rendering configurations.
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 …
The GrapheneOS maintainer clarifies that the slowdown is tied to memory safety checks and legacy C++ code rather than simple inefficiency.
Generated by an LLM from the article and thread. Check the sources before relying on it.