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
