This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 12/06/2017 02:40 PM, Joseph Myers wrote:
On Wed, 6 Dec 2017, Florian Weimer wrote:

Based on the 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]