Has there been any review of the CFI mechanism in Clang? Many CFI schemes were broken by CompSci reviewers without much trouble. It kept high-assurance security away from CFI for the most part in favor of memory safety (eg SVA-OS) or data-flow integrity which had higher cost. We just assumed the next CFI scheme would break. Code-Pointer Integrity (below) is only one I like at this point given it works on an OS & uses segments for protection. Still want it pentested, though.
HardenedBSD would provide a great place to do comparisons as it has integrated clang’s SafeStack implementation across (nearly) all of base in addition to enabling SafeStack for a good number of ports.
I’m working on doing the same with clang’s CFI. I have (nearly) all of HardenedBSD base compiled with CFI in the hardened/current/clang400-import branch in HardenedBSD’s playground repo. I currently run CFI’d HardenedBSD on my laptop and in some development VMs.
I’ve noticed the biggest offender is the cfi-icall scheme. Many applications (including bhyve) break with cfi-icall enabled. I’ll soon be digging in to find the root cause of the breakage.
Good work you’re doing there. SafeStack was in the paper along with CPS as watered down versions. A version of CPS was already broken. SafeStack is obviously limited. Do you have any plans to implement the full Code-Pointer Integrity for HardenedBSD? Is it even supported in LLVM?
Ideally, I’d prefer to port PaX Team’s RAP, which is in grsecurity. The problem is that the data structures in LLVM IR don’t provide enough data for RAP. In order to provide the level of granularity RAP needs in LLVM IR, extremely major and ugly hacks would be needed. The other problem is that of licensing. RAP is currently implemented in a GPLv3 toolchain (some newer version of gcc). To add further complexity, RAP is patented. In the end, we’re probably stuck with what’s in LLVM/clang.
That’s a long-winded version to say: HardenedBSD’s currently planning to stick with what LLVM/clang provides, though that may change in the future. The original authors and a few others are working on overhauling SafeStack to make it much more compatible with large codebases, like Firefox. We may or may not assist in those efforts.
Thanks for the detailed reply.