This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca avoidance patches
- From: Jeff Law <law at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: nd at arm dot com, GNU C Library <libc-alpha at sourceware dot org>, Rich Felker <dalias at libc dot org>
- Date: Mon, 19 Jun 2017 14:46:28 -0600
- Subject: Re: alloca avoidance patches
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.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 12E3C61D2D
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 12E3C61D2D
- References: <5a4e9615-8403-1854-a942-168bcd77d80b@redhat.com> <alpine.DEB.2.20.1706191644090.27712@digraph.polyomino.org.uk> <59480AD3.6@arm.com>
On 06/19/2017 11:33 AM, Szabolcs Nagy wrote:
> On 19/06/17 17:47, Joseph Myers wrote:
>> It seems to me that we need a clear definition of what stack frame size
>> glibc can assume is safe (so that we can aim to eliminate alloca and VLAs
>> unless the compiler can see they are bounded, and use -Wstack-usage= for
>> building glibc to make sure no function uses too much stack).
>
> my experience with musl is that the tricky recursive
> unbounded stack usage cases are not possible to catch
> with -Wstack-usage= (details below) and that it warns
> about several seemingly unbounded vlas that are clearly
> bounded after some manual analysis, i expect glibc
> would be similar.
The total stack usage isn't really the issue here. Yes, over-use can
contribute to bringing the stack and heap close together. But to jump
the guard you need an allocation greater than a page without touching
the page.
My focus is on avoiding the possibility of jumping the guard by using
probes. It's certainly good to limit unnecessary stack usage, but IMHO
it doesn't address the key choke point we have to mitigate these kinds
of attacks.
Jeff