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/05/2017 11:55 AM, James Greenhalgh wrote:

To be clear here, I'm coming in to the review of the probing support in GCC
late, and with very little context on the design of the feature. I certainly
wouldn't want to cause you worry - I've got no intention of pushing for
optimization to a larger guard page size if it would leaves things broken
for AArch64.

The situation with aarch64 is perhaps a bit complicated because we are faced with different kernel builds with different page sizes (4 KiB on the low end, 64 KiB for enterprise workloads).

If assuming that 64k probes are sufficient on AArch64 is not going to allow
us a correct implementation, then we can't assume 64k probes on AArch64. My
understanding was that we were safe in this as the kernel was giving us a
generous 1MB to play with, and we could modify glibc to also give us 64k
(I admit, I had not considered ILP32, where you've rightly pointed out we
will eat lots of address space if we make this decision).
You can't modify existing glibc installations which use one page for the guard. For a 32-bit address space, I hope the consensus is that we don't want to switch to multiple guard pages by default.

All this means that it will be very difficult to document the protection afforded by the -fstack-clash-protection option.

This problem goes away completely if you probe at intervals of the minimum page size the system supports because existing glibc versions will interoperate with that (in the sense that they provide the intended level of protection).


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