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

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