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: 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>
- Cc: 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:16:08 +0100
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.email@example.com> <firstname.lastname@example.org> <5A1EFF28.email@example.com> <firstname.lastname@example.org> <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com>
On 11/29/2017 11:28 PM, Wilco Dijkstra wrote:
It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to
run old binaries so a larger guard size is definitely beneficial. No existing code
uses probing, so increasing the guard size means far fewer functions could
jump the guard. The dropoff is exponential, each doubling of guard page size
halves the number of functions with a stack larger than the guard size.
That's not actually true in the sense that the math doesn't work out
that way. If you have a weird function which skips by a really large
amount, you can double the guard size many, many times until the number
of unprotected functions drops further.
And there is definitely a long tail here, due to GNU's affinity to
variable-length arrays and alloca.
That's why Linux went for a 1MB guard size.
The original intent was to ship only a kernel patch and not change ld.so
at all. Qualys did some math to support their recommendation, but it
turns out the 1 MiB guard size is insufficient to protect ld.so on some
architectures. That's why we had to patch ld.so, too.
So far, I haven't seen a strong argument that 64 KiB is better than 32
KiB, or that switching to 96 KiB or 128 KiB would not provide additional
protection. To me, it's still an arbitrary number.
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).