This is the mail archive of the
mailing list for the GCC project.
Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- From: Florian Weimer <fweimer at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law 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 20:15:55 +0200
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6C4277FD40
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6C4277FD40
- References: <firstname.lastname@example.org> <20170619172932.GV2123@tucnak> <759F8732-F3ED-4778-9CD6-9A4DF1015D44@gmail.com> <3FD871AF-91A5-4C77-B5CF-A1E66C02E486@gmail.com>
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.
(I believe the use of ORQ in the current -fstack-check probes might be
an oversight. For a start, the REX prefix seems completely unnecessary.)