This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Jeff Law <law at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Rich Felker <dalias at libc dot org>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Wed, 6 Dec 2017 07:44:03 -0700
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com> <91691187-15ae-e740-bea6-94eff4172263@redhat.com> <alpine.DEB.2.20.1712061338330.25325@digraph.polyomino.org.uk>
On 12/06/2017 06:40 AM, Joseph Myers wrote:
> On Wed, 6 Dec 2017, Florian Weimer wrote:
>
>> Based on the ld.so experience, I think it is questionable that existing
>> vulnerable applications can be fixed by increasing the guard size. Our
>> expectation is that we have to recompile with -fstack-clash-protection to get
>> deterministic crashes (which we are doing with glibc), or to patch them to
>> avoid the stack jump (which we did for ld.so because the GCC support wasn't
>> available at the time).
>
> I'd say we should continue to fix any cases of unbounded dynamic stack
> allocations in glibc, as being bugs (whether or not bugs with security
> impact), *and* expect to need to compile glibc and everything else with
> -fstack-clash-protection for safety (there are, after all, some quite
> large but bounded static stack allocations in glibc).
Agreed 100%.
An unbound dynamic allocation is a security vulnerability for multiple
reasons. Treating them as bugs is absolutely the way to go.
I'd personally go a step further and say that a dynamic allocation
managed by a human is also a problem waiting to happen. We've shown
that repeatedly through the decades. We just can't seem to get them
right ;(
Compiling critical code such as glibc with -fstack-clash-protection is
also highly desirable -- even on architectures that do not have
stack-clash protected prologues. You obviously get less protection on
such targets, but the primary vector for stack-jumps is dynamic
allocations in our experience and those are protected with generic code.
jeff