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

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 06/12/17 14:27, Wilco Dijkstra wrote:
> Florian Weimer wrote:
>> 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.
> 
> The math works fine for most of the curve. The measurements I did
> show that the number of functions with really large stack allocations is
> extremely small. So it's a long tail only in terms of maximum stack
> allocation, not in number of functions.

with 4k probe interval about 1% of functions need probes
with 64k probe interval about 0.01% (order of magnitude,
alloca not included), so increasing the default guard can
be useful for existing code.

however i have doubts about mandating 64k guard page size
on aarch64.

in principle 64k guard on aarch64 should not cause problems
since there are systems with 64k page size already,

but there are some glibc issues:

bug 11787 needs fixing (at least the guardsize accounting
part) to avoid wasting stack.

some applications control their own memory use via RLIMIT_AS
which means we cannot arbitrarily waste address space either.

the right logic for pthread_attr_init, __pthread_get_minstack,
pthread_getattr_default_np, pthread_getattr_np, allocate_stack,
__libc_alloca_cutoff is not obvious. and backporting a change
with minimal impact may be difficult.

but more importantly glibc cannot fix everything:

there are user allocated stacks where the user presumably
allocates the guard too and we cannot affect that.

there are other libcs and all of them use single guard page now
(bsd systems, bionic, musl, ..) other language runtimes may
explicitly set single guard page too (openjdk, erlang,..?) and
providing reduced security guarantees on all those systems is
suboptimal. (can we round up the guardsize setting?)

so the question is whether pagesize < 64k systems sometimes
getting reduced security because of small guard is worse or
users turning probing off because of 4k probing overhead.