You could give upstream the latest release of RAP but it wouldn't mean they would understand it and be able to maintain it. It can't simply be merged with no one developing / maintaining it. That is essentially what they did with a few plugins but they're much smaller/simpler.
Conversation
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.
1
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
It didn't work as intended on x86 since it has stack-based return addresses and they were still returning that way so there was a race. They didn't want to do something more invasive and it wasn't specifically for kernel where they could make stacks inaccessible to other threads.
1
1
arm64 is all that really matters to Android for the foreseeable future. There will be CET on x86 providing hardware shadow stack support and arm64 will be able to use ARMv8.5 / ARMv9 MTE (memory tagging) to make ShadowCallStack more secure if they decide to figure that out.
2
1
Good luck finding stuff that uses PA and MTE extension on the Android side of things
2
Last I check hardware CET and CET_SS was seeing the same lack of interest from major x86 vendors
1
CET was a feature created by Intel and they've started shipping it on their newer hardware. I have no clue what you mean by lack of interest. It's not up to anyone other than Intel and AMD to include it on their processors. They don't license the ISA, etc. to a bunch of vendors.
If you read the thread then you know that Android currently uses ShadowCallStack and Clang type-based CFI.
Top Byte Ignore has been in use for years via HWASan as partial hardware memory tagging support but it's too slow for production deployment and MTE HW isn't available yet.
1
ARM decided to continue using ARMv8.2 with certain extensions backported for their in-house core designs which is what held back broad adoption of newer features. Features like MTE are optional anyway. ARMv8.5 or ARMv9 support doesn't imply having support for MTE at all.