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

[Florian Weimer]

On 12/05/2017 11:55 AM, James Greenhalgh wrote:

> To be clear here, I'm coming in to the review of the probing support in GCC
> late, and with very little context on the design of the feature. I certainly
> wouldn't want to cause you worry - I've got no intention of pushing for
> optimization to a larger guard page size if it would leaves things broken
> for AArch64.

The situation with aarch64 is perhaps a bit complicated because we are 
faced with different kernel builds with different page sizes (4 KiB on 
the low end, 64 KiB for enterprise workloads).

> If assuming that 64k probes are sufficient on AArch64 is not going to allow
> us a correct implementation, then we can't assume 64k probes on AArch64. My
> understanding was that we were safe in this as the kernel was giving us a
> generous 1MB to play with, and we could modify glibc to also give us 64k
> (I admit, I had not considered ILP32, where you've rightly pointed out we
> will eat lots of address space if we make this decision).
You can't modify existing glibc installations which use one page for the 
guard.  For a 32-bit address space, I hope the consensus is that we 
don't want to switch to multiple guard pages by default.

All this means that it will be very difficult to document the protection 
afforded by the -fstack-clash-protection option.

This problem goes away completely if you probe at intervals of the 
minimum page size the system supports because existing glibc versions 
will interoperate with that (in the sense that they provide the intended 
level of protection).

Thanks,
Florian