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: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: nd <nd at arm dot com>
- Date: Wed, 21 Jun 2017 11:05:13 -0600
- Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.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 B720E3D956
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B720E3D956
- References: <AM5PR0802MB2610C07342688AA9A63FB3BA83C50@AM5PR0802MB2610.eurprd08.prod.outlook.com>
On 06/20/2017 05:22 PM, Wilco Dijkstra wrote:
> Jeff Law wrote:
>> But the stack pointer might have already been advanced into the guard
>> page by the caller. For the sake of argument assume the guard page is
>> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that
>> the caller hasn't touched the 0xf1000 page.
>> If FrameSize >= 32, then the stores are going to hit the 0xf0000 page
>> rather than the 0xf1000 page. That's jumping the guard. Thus we have
>> to emit a probe prior to this stack allocation.
> That's an incorrect ABI that allows adjusting the frame by 4080+32! A correct
> one might allow say 1024 bytes for outgoing arguments. That means when
> you call a function, there is still guard-page-size - 1024 bytes left that you can
> use to allocate locals. With a 4K guard page that allows leaf functions up to 3KB,
> and depending on the frame locals of 2-3KB plus up to 1024 bytes of outgoing
> arguments without inserting any probes beyond the normal frame stores.
> This design means almost no functions need additional probes. Assuming we're
> also increasing the guard page size to 64KB, it's cheap even for large functions.
I'm a little confused. I'm not defining or changing the ABI. I'm
working within my understanding of the existing aarch64 ABI used on
linux systems. My understanding after reading that ABI and the prologue
code for aarch64 is there's nothing that can currently be relied upon in
terms of the offset from the incoming stack pointer to the most recent
"probe" in the caller.
Just limiting the size of the outgoing arguments is not sufficient
though. You still have the dynamic allocation area in the caller. The
threat model assumes the caller follows the ABI, but does not have to
have been compiled with -fstack-check.
Thus you'd have to have an ABI mandated probe at the lowest address of
the dynamic allocation area and limit the size of the outgoing stack
arguments for your suggestion to be useful.
If ARM wants to update the ABI, that's fine with me. But until that
happens and compilers which implement that ABI are ubiquitous ISTM we
can't actually depend on those guarantees.
If I'm wrong and there is some guarantee we can rely on, let me know.
It's trivial to change the initial state to utilize such guarantees.