This is the mail archive of the
mailing list for the GCC project.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- From: Jeff Law <law at redhat dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>, 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>
- Date: Tue, 20 Jun 2017 14:45:58 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DCCA4C049E16
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DCCA4C049E16
- References: <firstname.lastname@example.org> <1668482.ocPt5K0QLh@polaris> <20170620194818.GL2123@tucnak> <2839350.GqtxodeRKm@polaris>
On 06/20/2017 02:37 PM, Eric Botcazou wrote:
>> 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.
I don't see MOVING_SP as painful, except perhaps on aarch64. On
something like PPC MOVING_SP turns out to be exceedingly clean.