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 11/29/2017 11:28 PM, Wilco Dijkstra wrote:
It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to
run old binaries so a larger guard size is definitely beneficial. No existing code
uses probing, so increasing the guard size means far fewer functions could
jump the guard.  The dropoff is exponential, each doubling of guard page size
halves the number of functions with a stack larger than the guard size.

That's not actually true in the sense that the math doesn't work out that way. If you have a weird function which skips by a really large amount, you can double the guard size many, many times until the number of unprotected functions drops further.

And there is definitely a long tail here, due to GNU's affinity to variable-length arrays and alloca.

That's why Linux went for a 1MB guard size.

The original intent was to ship only a kernel patch and not change at all. Qualys did some math to support their recommendation, but it turns out the 1 MiB guard size is insufficient to protect on some architectures. That's why we had to patch, too.

So far, I haven't seen a strong argument that 64 KiB is better than 32 KiB, or that switching to 96 KiB or 128 KiB would not provide additional protection. To me, it's still an arbitrary number.

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


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