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>, Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 20 Jun 2017 09:50:20 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.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 393253D954
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 393253D954
- References: <email@example.com> <20170619181200.50E0C33CA8@vlsi1.gnat.com> <1668482.ocPt5K0QLh@polaris>
On 06/20/2017 02:21 AM, Eric Botcazou wrote:
>> Out of curiousity, does the old Alpha/VMS stack-checking API meet the
>> requirements? From what I recall, I think it does.
> No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it
> because of valgrind. I'd personally rather change valgrind but...
I'm torn here. It'd certainly be a hell of a lot easier to punt this to
valgrind, but with the issues I just couldn't get comfortable with that.
We're probing pages which are potentially unmapped and far away from the
stack pointer. The kernel and/or valgrind has to look at the reference
and make a guess whether or not it's really a request for more stack or
a wild pointer -- and there's no real good way to tell the difference.
Thus we're dependent upon the heuristics used by the kernel and valgrind
and we're dependent on those heuristics essentially being the same (and
I'm certain they are not at this time :-)
One could also argue that these probes are undefined behavior precisely
because they potentially hit pages unmapped pages far away from the
Any probing beyond the stack pointer is also going to trigger a valgrind
warning. Valgrind has some support avoiding the warning if a reference
hits the red zone -- but these probes can be well beyond the red zone.
In a world where distros may be turning on -fstack-check=<whatever> by
default, valgrind has to continue to work and not generate an
unreasonable number of false positive warnings else the tool becomes