[llvm-dev] [RFC] stack clash protection for x86

[Serge Guelton via llvm-dev]

Hi folks,

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 [0] 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 [1].

Implementation-wise, the mitigation implemented in GCC [1] 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

[0] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
[1] https://pagure.io/fesco/issue/2020
[2] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html