So, sure, you can avoid 100-200ms extra time for cold start app spawning by not using exec spawning. You are paying a substantial security cost to avoid it. The same goes for other features like hardened_malloc. We use hardened_malloc in a very security-focused configuration too.
Conversation
What's the substantial security cost? What could go wrong in terms of security? Can someone remotely gain access to my phone? Is it a physical security cost?
1
1
Read the grapheneos.org/usage#exec-spa section.
Not using exec spawning makes code execution exploits against apps substantially easier for attackers. It makes it substantially easier for an attacker to exploit apps. It cripples a bunch of standard security features and ones we add.
1
Most local and remote code execution vulnerabilities are heap corruption vulnerabilities. Our hardened_malloc project is a counter to those, and provides important protections against them. It also doesn't slow down Java or Kotlin at all. This is the whole point of GrapheneOS.
1
4
GrapheneOS is not a branded build of AOSP with various tweaks and bundled apps. It's AOSP with substantial privacy and security improvements. Better permissions, stronger app sandbox, much stronger protections against remote / local compromise by attackers, better encryption, etc
1
1
AOSP is Android without Google apps and services included. GrapheneOS is AOSP with substantially better privacy and security via a bunch of added features improving those. You should read the information on our site. Many people seem to be quite confused about what GrapheneOS is.
1
1
What we provide isn't simply a branded build of AOSP with updates, standard Android privacy / security and without Play Services.
CalyxOS is not GrapheneOS with microG and bundled apps. It doesn't have our privacy and security improvements which is the whole point of GrapheneOS.
1
2
We're not willing to sacrifice more than ~20% throughput and we aren't willing to make changes with a substantial impact on latency or the user experience. Cold start app spawning time is one of the few noticeable impacts, and primarily only on a 3a because the hardware sucks.
1
There's a point at which the storage and CPU is fast enough that freshly spawning a new app instead of cloning the same template isn't noticeable. Pixel 3a regressed far back into it being noticeable. Still, it only happens once, until memory is low and the OS closes the app.
1
1
The main issue is that the Pixel 3a uses eMMC storage instead of a proper high performance SSD. Even the first generation Pixels used UFS 2.0. Pixel 4a has UFS 2.1 so it shouldn't be nearly as much of an issue. Non-exec spawning clones a basic app template already in memory.
1
1
So with non-exec spawning, it very quickly has an app spawned that's already largely in memory. It still has to deal with loading and initializing everything specific to that app. Android has optimized app spawning largely by preloading more things into the template they clone.
Exec-based spawning could be substantially optimized: after launching an app, we could start spawning the next app process to have it ready. We'd rather keep it simple and focus on adding more privacy/security features, fixing AOSP bugs uncovered by hardened_malloc, etc.
1
lifeasageek.github.io/papers/lee-mor is an old paper about it. It doesn't cover all the disadvantages of the standard spawning model and is focused only on ASLR.
We stopped thinking much about this after the Pixel 1 due to UFS storage. Pixel 3a made this an issue people notice again. *shrug*