Re: [RFC] nptl: change default stack guard size of threads

[Florian Weimer <fweimer at redhat dot 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).

Thanks,
Florian