This is the mail archive of the
mailing list for the GCC project.
SafeStack proposal in GCC
- From: Cristina Georgiana Opriceana <cristina dot opriceana at gmail dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Volodymyr Kuznetsov <vova dot kuznetsov at epfl dot ch>, Lucian Mogosanu <lucian dot mogosanu at cs dot pub dot ro>, george dot candea at epfl dot ch, Razvan Deaconescu <razvan dot deaconescu at cs dot pub dot ro>
- Date: Wed, 13 Apr 2016 16:01:46 +0300
- Subject: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
I bring to your attention SafeStack, part of a bigger research project
- CPI/CPS , 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 . Safestack
has been recently merged into the Clang/LLVM mainline .
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
We appreciate your feedback and remarks on this proposal.