The main issue with adoption for Android is that CFI is still only universally enabled for the kernel, not userspace. It's not being pushed onto app developers via the NDK. There's also a lot of low hanging fruit from the Android Runtime although we address a lot ourselves.
Conversation
It's great that the majority of app code is written in memory safe languages.
However, apps still use plenty of a native code and most of that is loaded via dynamic libraries rather than in separate native processes. Runtime for Kotlin/Java provides low-hanging fruit to target.
1
2
Yeah, Android's case, the ecosystem is controlled much tighter.
In HardenedBSD, we have to deal with whatever weird things developers of 32,000+ projects decide to do.
3
Yeah, app developers will have to deal with it when the NDK starts doing it as has been done for the earlier features. Android removed non-PIE dynamic executables completely along with many other legacy things like text relocations thanks to new archs (arm64) and API levels.
1
2
Apps are always meant to be built with the latest SDK but they can take time to move to targeting the latest API level. Targeting newer API levels enables backwards incompatible improvements which app developers are forced to adopt. Lots of privacy/security improvements are done.
1
1
There's a list of developer-facing changes in 12 at developer.android.com/about/versions for example. Blatantly backwards incompatible changes are limited to apps targeting the new API level and above (API 31 for Android 12).
Play Store currently requires API 30+ for new apps / app updates.
1
1
Android 10 (API 29) started imitating memory tagging for malloc so modern apps are already prepared for having data added to the upper bits in pointers and if they aren't they're explicitly turning it off already.
source.android.com/devices/tech/d
Actual tagging will probably be API 33+.
1
1
Too many apps have latent memory corruption bugs that are going to be uncovered. It'll likely end up being phased in via API level. Eventually apps won't have the option to turn it off anymore after a certain API level. It's a nice way of being able to gradually do these changes.
1
1
App developers get around 4-6 months of the new major OS version being in public Beta testing and then they get about a year after the stable release before the Play Store forces them to target the new API level.
Of course, can't do that for our changes unless we upstream them.
1
1
Some of our changes would really benefit from being upstream so app developers could be forced to cope with it such as our OTHER_SENSORS (Sensors) permission where we currently have to assume every app needs it and have to leave it enabled by default.
1
1
Their approach would be adding it for a new API level and forcing apps to declare it + request it from that point forwards, with it automatically added for legacy apps, and then eventually legacy apps would have the OS request it on first launch once they become very rare.
I wish we could force a change on the app ecosystem that way ourselves since there are dozens of things we'd be able to do in a nicer way. It's still pretty easy for us to make fairly aggressive changes due to how apps are forced to work by doing things through the OS APIs.
1