SafeStack proposal in GCC

Jeff Law
Wed Apr 27 22:46:00 GMT 2016

On 04/13/2016 07:01 AM, Cristina Georgiana Opriceana wrote:
> 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.
This all sounds good.  And I'd definitely look to re-use the runtime and 
perhaps tests from Clang.


More information about the Gcc mailing list