[PATCH] Protection against stack-based memory corruption errors using SafeStack

[Laszlo Szekeres]

On Fri, May 29, 2015 at 10:23 AM, Kostya Serebryany <kcc at google.com> wrote:

> > My concern is that IR may look OK in the tests, but further passes or
> the ISA-specific lowering could leak the safe stack's location.
>

Please note, that the current patch does not do anything against leakage.
The primary issue with preventing leaks is not necessarily the generated
machine code, but libraries. For instance, libc definitely leaks the stack
pointer in several ways (e.g., setjmp, getcontext, sigset, etc.). The idea
is that going forward, we'd fix these in libc and in other low-level
libraries, by either eliminating the escaping/dumping of %rsp when that's
possible, or by using encryption/PTR_MANGLE (XOR-ing the dumped stack
pointer with another secret we control and protect better). This is
actually already done for setjmp in glibc, for example.

I was planning to write a static binary verifier at some point, that would
make sure that the stack pointer is either not written to memory, or if it
is, its written only to the safe stack. Verifying that it's never stored
can be done with a pretty simple intra-procedural data-flow analysis on the
assembly code. Checking that the stack pointer spilled to the (safe) stack
never leaves the (safe) stack is a bit harder, due to aliasing (e.g. push
%rsp, then later mov (%rsp-8), %rax; mov %rax, (%rdi)), but it can be done
as well. This verifier could be included as machine function pass in the
code generator or in the assembler later on.

Laszlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150529/51af0a21/attachment.html>