<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 29, 2015 at 10:23 AM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> 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.<br></span></blockquote></div><br><div class="gmail_extra"><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div><div><br></div><div>Laszlo</div></div></div>