This is the mail archive of the
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Cristina Georgiana Opriceana <cristina dot opriceana at gmail dot com>, <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>, nd <nd at arm dot com>
- Date: Wed, 20 Apr 2016 15:54:15 +0100
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <CAFA9rWPkb=eV0GhvFeOnd4pRVh=N3fSifYBwZjy9Ndh68BmBww at mail dot gmail dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
> 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 think it does not provide complete protection.
it cannot instrument the c runtime or dsos and attacks
can be retried on a forking server which has fixed memory
layout, so there is still significant attack surface.
(it would be nice if security experts made such claims
much more carefully).
> In GCC, we propose a design composed of an instrumentation module
> (implemented as a GIMPLE pass) and a runtime library.
> 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
the SafeStack runtime in compiler-rt has various issues
that should be clearly documented.
it seems the runtime
* aborts the process on allocation failure.
* deallocates the unsafe stack using tsd dtors, but
signal handlers may run between dtors and the actual
thread exit.. without a mapped unsafe stack.
* determines the main stack with broken heuristic
(since the rlimit can change at runtime i don't think
this is possible to do correctly in general).
* interposes pthread_create but not c11 thrd_create
so conforming c11 code will crash. (same for non-standard
usage of raw clone.)
* sigaltstack and swapcontext are broken too.
i think the runtime issues are more likely to cause
problems than the compiler parts: it has to be reliable
and abi stable since safestack is advertised for
(i think gcc should raise the bar for runtime code
quality higher than that, but there is precedent
for much worse runtimes in gcc so this should not
block the safestack porting work, however consider
these issues when communicating about it to upstream
or to potential users.)