Yeah, that's why we still use SafeStack for applications in HardenedBSD base. Eventually, we'll work on migrating away from SafeStack to something better.
I'm working on Cross-DSO CFI support in HardenedBSD. We'll get there eventually.
Conversation
The problem I face with working on Cross-DSO CFI: it requires large chunks of consecutive time sitting in my chair doing R&D. With large responsibilities at ${DAYJOB}, a family, and ${HEALTH_ISSUES}, it's growing more and more difficult for me to make tangible progress.
1
Another problem is that we build over 30,000 packages. Building libc with CFI breaks a freakton of things.
And reading llvm CFI's source, it appears it wasn't really designed to support applying CFI to libc.
2
1
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.
1
2
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+.
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
Show replies