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

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