This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Florian Weimer <fweimer at redhat dot com>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: Rich Felker <dalias at libc dot org>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Wed, 6 Dec 2017 13:50:56 +0100
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <20171129205148.GG1627@brightrain.aerifal.cx> <00c123b5-dd46-6777-2c24-d80eae8d35df@redhat.com> <20171205105530.GA12966@arm.com>
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).
Thanks,
Florian