SafeStack proposal in GCC

[Li Kun]

I have noticed this topic in history of gcc ml, how is that going with 
this feature?
I have much interest in this feature and am trying to do sth in these days.
There are some questions about the design you mentioned.
As my understanding, a single gimple pass is not enough for safestack, 
for example
if an aggregate type arg is passed by reference, it may be copied to a 
stack slot of caller,
and the pointer will be passed to callee, that will break the rule of 
safestack. So
i think we should do something in expand pass or need another pass after 
expand.
> 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

-- 
Best Regards
Li Kun