Hello, I bring to your attention SafeStack, part of a bigger research project - CPI/CPS [1], which offers complete protection against stack-based control flow hijacks. I am interested in developing SafeStack for GCC and I would like to ask for your feedback on this proposal.
SafeStack is a security mechanism that protects against stack based control flow attacks, while also keeping a low runtime overhead - it prevents all stack-based attacks in the RIPE benchmark, and has just 0.05% overhead on average on SPEC CPU2006 benchmarks [2]. Safestack has been recently merged into the Clang/LLVM mainline [3]. Its design is based on the separation of stack-allocated memory objects in two regions: the safe stack, where we keep the return addresses, spilled registers and local variables proved to be only accessed in a safe way by a static analysis pass at compilation, and the regular region, where we move everything else. With this separation and randomized-based isolation of the safe stack, we ensure that no overflows from the unsafe stack can overwrite sensitive data from the safe stack. Further on, the isolation mechanism can be improved to use hardware segment protection or hardware extensions, such as Intel Memory Protection Keys. We aim to extend all of CPI into the GNU userland, but start with a SafeStack port in GCC. In GCC, we propose a design composed of an instrumentation module (implemented as a GIMPLE pass) and a runtime library. The instrumentation pass will perform static analysis to discover stack objects that are only accessed in a safe way. It will also insert code that allocates a stack frame for the rest of the objects, those that did not satisfy the safety condition. The pass will run independently, after GIMPLE lowering, scheduled on the all_passes list and after other optimizations, such as dead code elimination. Then, all accesses to unsafe objects have to be re-written, based on the new stack base and offset in the unsafe stack. In the first phase of the implementation, the unsafe stack will be allocated on the heap, and we will rely on ASLR for the isolation. The runtime support will have to deal with unsafe stack allocation - a hook in the pthread create/destroy functions to create per-thread stack regions. This runtime support might be reused from the Clang implementation. We appreciate your feedback and remarks on this proposal. Thank you, Cristina [1] http://dslab.epfl.ch/proj/cpi/ [2] http://dslab.epfl.ch/pubs/cpi.pdf [3] http://clang.llvm.org/docs/SafeStack.html
