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: Richard Biener <richard dot guenther at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Jan Hubicka <jh at suse dot cz>, Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 20 Jun 2017 15:57:37 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.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 91B437486C
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 91B437486C
- References: <firstname.lastname@example.org> <20170619172932.GV2123@tucnak> <email@example.com> <20170619175149.GY2123@tucnak> <CAFULd4Z98CnqziqTg4GKE8uomepdzkpSeMQ40n1kF=cpA973PA@mail.gmail.com> <CAFiYyc1vAukq31r0CjEpfETAk6MTUVpFuhTapftP6179Q5FL=A@mail.gmail.com> <CAFULd4YPYze+ngEq74JW75=jibk6YVL-JvvKD4z-4aF1TZN_=Q@mail.gmail.com> <firstname.lastname@example.org> <CAFULd4YsYwN1saXYySMnNy4r=f6R1wbe0K4pOMmHM75HYJ5dQg@mail.gmail.com> <CAFULd4Y1GBiyv=Cn6R_j3mtinbdqxHen5VbkA1Z1UXQKBRU0gg@mail.gmail.com> <CAFiYyc1x-DQVg6uX8765dHLYMbnHLW_v-Sk8mRpLHPKmDQJCemail@example.com>
On 06/20/2017 06:27 AM, Richard Biener wrote:
> On Tue, Jun 20, 2017 at 2:20 PM, Uros Bizjak <firstname.lastname@example.org> wrote:
>> On Tue, Jun 20, 2017 at 2:17 PM, Uros Bizjak <email@example.com> wrote:
>>> On Tue, Jun 20, 2017 at 2:13 PM, Florian Weimer <firstname.lastname@example.org> wrote:
>>>> On 06/20/2017 01:10 PM, Uros Bizjak wrote:
>>>>> 74,99% a.out a.out [.] test_or
>>>>> 12,50% a.out a.out [.] test_movb
>>>>> 12,50% a.out a.out [.] test_movl
>>>> Could you try notl/notb/negl/negb as well, please?
>>> These all have the same (long) runtime as test_or.
>> Perhaps we can use "testb $0, %0"? It doesn't write to the memory, but
>> otherwise has the same runtime as movb/movl.
> That sounds good, OTOH it's a matter of putting strain on the
> memory fetch or store side... We'll get cacheline allocations in
> any case (but the memory will be used eventually). Instead
> of test a mere movb into a scratch register (aka, load instead of
> store) would work as well apart from the need of a scratch register.
It was never clear to me why we always implement probes via stores --
though from development standpoint a destructive store is useful.
I'd expect a tst to generate the desired SEGV.
How does that like compare to the partial-allocation + push approach?
> We can also vectorize with scatters ;) (just kidding)