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

[Florian Weimer <fweimer@redhat.com>]

On 11/29/2017 07:29 PM, Rich Felker wrote:
> On Wed, Nov 29, 2017 at 10:16:54AM -0800, Carlos O'Donell wrote:
>> On 11/29/2017 07:18 AM, Florian Weimer wrote:
>>> On 11/29/2017 03:59 PM, Szabolcs Nagy wrote:
>>>> The change can be made for aarch64 only
>>>
>>> That doesn't seem to be the case, looking at the patch.
>>>
>>> So what you intended to do, exactly?
>>>
>>> A 64 KiB probe interval on legacy 32-bit architectures is really a
>>> no-go.  It means we have to increase the guard region size to 64 KiB.
>>> But we cannot do that: The guard allocation comes out of the overall
>>> thread stack size, and existing applications do not expect that 60K
>>> of configured stack suddenly becomes unavailable.  Adding the guard
>>> size on top of the allocation will break setups which are carefully
>>> tuned for a maximum number of threads.
>>
>> We cannot be held to account for carefully tuned applications, such
>> applications have to be tuned again for newer glibc.
>>
>> I think we *could* do this for 64-bit and 32-bit AArch64/ARM, but I
>> don't see the value in doing it for 32-bit.
> 
> If 64k guard is mandatory for safety against jumping over the guard
> zone, then I don't think it's possible to "re-tune" 32-bit apps for
> the new requirement. This imposes a relatively small limit on possible
> number of threads the process can create.

With the probing implementations I have seen so far, it is feasible 
technically because a probe will never touch a stack area which could 
not conceivably be touched by a signal handler, too.

But it is still a bad situation when GCC documents that it is only 
providing full protection with guard size X, and you decide to run with 
size X/16 to actually get things going.  This means that your 
configuration is out of scope what your vendor will support 
security-wise, and probably non-compliant with applicable guidelines at 
the user site.

So technically you can run with a smaller guard size, but it's still 
impractical to do so for most organizations.

Thanks,
Florian