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

[Florian Weimer <fweimer at redhat dot com>]

On 12/06/2017 02:40 PM, Joseph Myers wrote:
> On Wed, 6 Dec 2017, Florian Weimer wrote:
>
> > 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).
>
> I'd say we should continue to fix any cases of unbounded dynamic stack
> allocations in glibc, as being bugs (whether or not bugs with security
> impact), *and* expect to need to compile glibc and everything else with
> -fstack-clash-protection for safety (there are, after all, some quite
> large but bounded static stack allocations in glibc).

Yes, I was too brief.  Any reachable large stack jump still needs to be 
fixed.  But it's very hard to identify those that matter.  Aldy and I 
actually looked at the llp_tmp jump long before the security impact was 
known, but I dismissed, probably because I wrongly assumed that 
LD_LIBRARY_PATH is ignored in AT_SECURE=1 binaries.

So -fstack-clash-protection is needed for the deterministic crashes, as 
a safety net, but it of course doesn't fix any actual bugs.

Thanks,
Florian