This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] aarch64: enforce >=64K guard size
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, <law at redhat dot com>, <dalias at libc dot org>
- Date: Tue, 16 Jan 2018 16:04:37 +0000
- Subject: Re: [PATCH v3] aarch64: enforce >=64K guard size
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 217.140.96.140) smtp.mailfrom=arm.com; redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=bestguesspass action=none header.from=arm.com;
- Nodisclaimer: True
- References: <5A54987B.6040305@arm.com> <5A55FD81.6040006@arm.com> <f3320c7e-0b8f-3f77-b70f-69d959e460c3@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Thu, Jan 11, 2018 at 09:32:23AM +0000, Florian Weimer wrote:
> On 01/10/2018 12:48 PM, Szabolcs Nagy wrote:
> > meanwhile this passed a build-many-glibcs.py test
> > is this ok for 2.27 ?
>
> I don't think the GCC patch has been committed yet.
>
> I find it baffling what's going on there. Aren't the ARM maintainers
> interested in this feature?
Last I saw in December, we were making some good progress towards a conclusion
over here, which will guide the GCC support. Here is what I proposed then:
https://sourceware.org/ml/libc-alpha/2017-12/msg00630.html
Our proposal then, having spoken things through with the Arm engineers
here, and taken in to consideration the opinions on this thread, is that
we move to two "blessed" configurations of the GCC support for AArch64.
One would assume 64k guard pages. This would work out-of-the-box on systems
with a 64k page size, and would work with modifications to glibc (and other
libraries as appropriate) on systems with a 4k (or other) page size. The
performance impact will be low. If we take this approach, this will be the
default configuration for GCC.
The other would assume 4k guard pages. This would work everywhere, and
as-good-as guarantee complete coverage. However, it would be inefficient
on systems with a larger page size, or with a glibc upgraded to use
64k guard-pages.
You replied:
https://sourceware.org/ml/libc-alpha/2017-12/msg00635.html
So if this is some sort of consensus proposal, as opposed to actual
technical requirements which favor Option 2 in some deployments, I think
that's not a good idea, and we should go with Option 1 instead.
To which Szabolcs replied:
https://sourceware.org/ml/libc-alpha/2017-12/msg00662.html
well glibc can pretend that only Option 1 is available,
my latest patch assumes 64k probe interval:
https://sourceware.org/ml/libc-alpha/2017-12/msg00451.html
however Option 1 requires generic code to be changed
for aarch64 only (in the libc and elsewhere) and we
cannot easily do that on all (non-glibc) systems.
it seems to me if there are systems where Option 1
may not provide guaranteed trap on stack overflow
then gcc should have Option 2 for those systems.
Which to me would imply that, as Szabolcs has said, this patch is the correct
thing to do regardless of what we do in GCC.
The GCC requirements from non-glibc targets remain unclear to me. Rich
said:
https://sourceware.org/ml/libc-alpha/2017-12/msg00682.html
For what it's worth, I would prefer having the assumed minimum guard
size be 4k for musl targets. Even if we do increase the default guard
to 64k for 64-bit archs (seems likely), applications that manually set
it lower for whatever reason should still be handled safely.
So, for me, that makes the GCC path clear - the compromise/consensus proposal
to have two modes is the only way to unify the glibc and musl requirements.
That goes against what Jeff would ideally like:
https://sourceware.org/ml/libc-alpha/2017-12/msg00700.html
Ideally we set the guard size now and never ever decrease it. I'd
really like to remove the option to make it a compile-time configurable
--param for GCC. ie, it's baked into the port and never changes.
But seems to be the only sensible way to bridge the gap between what different
C librarians and users expect.
The GCC side conversation finished here just before I took a break for
Christmas https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01211.html I'll write
a reply to Jeff soon and try to pin down what needs to happen next with the
AArch64 GCC side. I do care about this feature, and would like it in GCC 8,
there are a fair amount of competing requirements on the patch for AArch64.
All that said, Szabolcs' patch over here looks correct, and makes a clear
statement about what we can expect as we progress the glibc support. We
still have a little time before the GCC 8 release, and the GCC patch will
require slight rework around the SVE patch anyway. If we have agreement over
here, we at least know what we're working towards.
Is there some reason I'm missing that Szabolc's patch would be incorrect,
regardless of what we do in GCC? If not, I'd suggest taking it.
Thanks,
James