This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, law at redhat dot com
- Date: Tue, 20 Jun 2017 22:37:47 +0200
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- References: <bef46e40-8004-0f80-4928-ad0795eb76ba@redhat.com> <1668482.ocPt5K0QLh@polaris> <20170620194818.GL2123@tucnak>
> But then valgrind won't be able to find bugs in the code (storing and later
> reading stuff into the volatile parts of the stack that could be overwritten
> by any asynchronous signal). GCC had various bugs in this area and
> valgrind has been able to report those. Unless the probe instruction is
> sufficiently magic that it won't usually appear in other code.
Right, maybe this magic aspect was the reason why it was initially implemented
like that for Cygwin, at least you know that orl $0 is meant to be special.
> Only checking loads below the stack is not sufficient, some buggy code could
> e.g. store some data below stack pointer (below red zone if any), then
> subtract stack and then try to read it, etc.
>
> Not to mention that it isn't just false positive messages with current
> valgrind on -fstack-check code, e.g. on ppc64 it just crashes.
The reasoning seems weird though since, apart from x86/x86-64, you're going to
gratuitously inflict this painful "moving sp" thing to every program compiled
on Linux because of just one tool that you can adapt.
--
Eric Botcazou