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>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 19 Jun 2017 11:45:13 -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 9A396C001F3B
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9A396C001F3B
- References: <bef46e40-8004-0f80-4928-ad0795eb76ba@redhat.com> <20170619172932.GV2123@tucnak>
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.
2. I would *prefer* if the probe actually changed the value, and the
more destructive, the better :-0 It allows catching something gone
wild easier.
These are pretty minor implementation details IMHO, but now is a good
time to revisit the probe style.
I'm mostly concerned about holes in the basic probing strategy, how
we're going to deal with the additional architectures (I can't imagine
we'll want to go through the pain of a custom implementation for each
target) and the UI.
On the last topic. When we first started this work, it appeared like we
could make most targets with -fstack-check=specific support work
(possibly with some inefficiency) by just dropping the
probe-ahead-of-need aspects of the existing implementation.
ie, we'd drop the requirement for being able to run the signal handler
and stop probing 2 pages beyond the current stack requirements and
instead just probe up to what the current function needed.
This felt like a "probing policy" (ahead-of-need vs as-needed).
But when we ran into the issues with valgrind it became clear that we
really couldn't safely use the current port support for
-fstack-check=specific.
Thus I find myself rethinking is this a probing policy option or should
it just be another variant of -fstack-check=<something>.
Jeff