RAP was publicly available including the deterministic hash-based forward and backward edge protection. It doesn't really seem like anyone else learned anything from it. The state of the art elsewhere is the much slower Clang CFI which leaves backward edge CFI to something else.
Conversation
The backward edge protection is SafeStack, which has issues. There's ways around SafeStack and it's in an incomplete state. It doesn't protect shared objects, only application code.
I've done some work in hbsd to get shared object support working, but my priorities keep shifting
1
The shared object support needs tight integration with both the RTLD and libc, in somewhat similar fashion as SSP, but a bit more complex.
If I remember correctly, setjmp/longjmp is still an issue with SafeStack.
1
SafeStack wasn't really meant to be used with Clang CFI. It was meant to be used as part of a broader CPI feature which was never finished or landed.
Android started adopting SafeStack including shared object support. It was dropped and it now uses ShadowCallStack instead.
2
1
SafeStack has serious issues with leaks since it uses the main thread stack as the main safe stack but there are assorted pointers to data libc places in it.
Android uses cross-DSO CFI and ShadowCallStack for both the kernel and userspace. ShadowCallStack is arm64 only though.
2
1
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.
2
2
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.
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
Not to mention just how many different languages/runtimes/toolchains are used.