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: Florian Weimer <fweimer at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jun 2017 15:57:42 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.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 AF1AB8046A
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AF1AB8046A
- References: <firstname.lastname@example.org> <20170619172932.GV2123@tucnak> <759F8732-F3ED-4778-9CD6-9A4DF1015D44@gmail.com> <3FD871AF-91A5-4C77-B5CF-A1E66C02E486@gmail.com> <email@example.com>
On 06/19/2017 12:15 PM, Florian Weimer wrote:
> On 06/19/2017 08:02 PM, Richard Biener wrote:
>> Oh, and using push intelligently with first bumping to SP & 4096-1 + 4095 would solve the signal atomicity as well. Might be larger and somewhat interfere with CPUs stack engine. Who knows...
> On x86-64, PUSH REG is just a single byte, so for sequences that have to
> move SP and probe, it's the shortest possible sequence AFAIK. NEG/NOT
> can take an offsettable memory operand, but it's three bytes.
Right. I think we want guidance from Honza & Uros on what the most
runtime efficient mechanisms are (or are likely to be, there's a certain
amount of guesswork that has to happen here), then we look at which are
the most code space efficient. I'm personally willing to trade off some
unwinder table space if it gives us more compact code.