This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery 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>, Jeff Law <law at redhat 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 14:51:01 +0100
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.firstname.lastname@example.org> <email@example.com> <5A1EFF28.firstname.lastname@example.org> <email@example.com> <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com>
On 12/06/2017 02:40 PM, 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).
Yes, I was too brief. Any reachable large stack jump still needs to be
fixed. But it's very hard to identify those that matter. Aldy and I
actually looked at the llp_tmp jump long before the security impact was
known, but I dismissed, probably because I wrongly assumed that
LD_LIBRARY_PATH is ignored in AT_SECURE=1 binaries.
So -fstack-clash-protection is needed for the deterministic crashes, as
a safety net, but it of course doesn't fix any actual bugs.