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

[Jeff Law]

On 12/06/2017 06:40 AM, 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).
Agreed 100%.

An unbound dynamic allocation is a security vulnerability for multiple
reasons.  Treating them as bugs is absolutely the way to go.

I'd personally go a step further and say that a dynamic allocation
managed by a human is also a problem waiting to happen.  We've shown
that repeatedly through the decades.  We just can't seem to get them
right ;(


Compiling critical code such as glibc with -fstack-clash-protection is
also highly desirable -- even on architectures that do not have
stack-clash protected prologues.  You obviously get less protection on
such targets, but the primary vector for stack-jumps is dynamic
allocations in our experience and those are protected with generic code.

jeff