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

JF Bastien jfb at chromium.org
Fri May 29 15:06:55 PDT 2015


In http://reviews.llvm.org/D6094#181289, @lszekeres 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.


I think this would be a pretty great addition to the documentation. Expand the caveats section, and document what can be done to fix them.


http://reviews.llvm.org/D6094

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list