[llvm-dev] [RFC] stack clash protection for x86
Serge Guelton via llvm-dev
llvm-dev at lists.llvm.org
Wed Oct 9 12:11:32 PDT 2019
this is a request for comment for on-going work on stack clash mitigation for Clang/LLVM. As a reminder, stack clash is a two-year old vulnerability  that triggers when stack expansion should make it hit a *page guard* inserted by the kernel, but an attacker manages to jump over the guard.
It would be nice for clang to achieve feature parity with gcc on that topic. For instance, -fstack-clash-protection is on by default on Fedora, so moving from gcc to clang to build a package like fedora would be considered as a security downgrade .
Implementation-wise, the mitigation implemented in GCC  basically inserts probes every PAGE_SIZE, splitting large stack allocation into an interleave of allocation and memory probes.
The job is made easier on x86 where calling convention enforce a write to the stack when pushing the return address, and that's the reason why I only covered this architecture for starters.
Compared to the GCC implementation, this patch makes a decent attempt at reusing existing memory operations involving stack read/writes in the function premable instead of generating artificial probes. It also warns about inline assembly involving stack pointer clobbering not being instrumented (I assume that's a rare case, but better safe than sorry).
I don't have benchmarks to present yet, but as it's my first time playing with CodeGen/Backend, I'll happily take feedbacks about the approach: everything is done in the x86 backend, during function frame lowering, so there's not much potential code sharing with other architectures and I wonder if that state could be improved.
The patch needs reviewers! https://reviews.llvm.org/D68720
More information about the llvm-dev