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: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Uros Bizjak <ubizjak at gmail dot com>, Jan Hubicka <jh at suse dot cz>
- Cc: Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jun 2017 15:51:45 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.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 8FCBAC0587FB
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8FCBAC0587FB
- References: <bef46e40-8004-0f80-4928-ad0795eb76ba@redhat.com> <20170619172932.GV2123@tucnak> <6b026ac5-7b68-f93b-e005-17288163f442@redhat.com> <20170619175149.GY2123@tucnak>
On 06/19/2017 11:51 AM, Jakub Jelinek wrote:
> On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote:
>> On 06/19/2017 11:29 AM, Jakub Jelinek wrote:
>>>
>>> Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack,
>>> while it is shorter, is it actually faster or as slow as movq $0, (%rsp)
>>> or movl $0, (%esp) ?
>> Florian raised this privately to me as well. THere's a couple issues.
>>
>> 1. Is there a performance penalty/gain for sub-word operations? If not,
>> we can improve things slighly there. Even if it's performance
>> neutral we can probably do better on code size.
>
> CCing Uros and Honza here, I believe there are at least on x86 penalties
> for 2-byte, maybe for 1-byte and then sometimes some stalls when you
> write or read in a different size from a recent write or read.
Obviously, I'll go with whatever Honza & Uros say is the most efficient.
This stuff would be highly localized and is easily tweaked into
whatever final form we want.
>
>> Thus I find myself rethinking is this a probing policy option or should
>> it just be another variant of -fstack-check=<something>.
>
> Yeah, IMHO it is just another way of stack probing next to generic and
> specific, and for users it would be easier to write -fstack-check=whatever
> than -fstack-check -fstack-check-probe=whatever
That's essentially where I'm leaning now. The difficulty is in
selecting a name. ISTM that -fstack-check=specific becomes horribly bad
though. It should really be -fstack-check=ada or somesuch.
jeff