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

Joseph Myers joseph@codesourcery.com
Wed Dec 6 13:40:00 GMT 2017


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).

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Libc-alpha mailing list