Re: [PATCH v3] aarch64: enforce >=64K guard size

[James Greenhalgh <james dot greenhalgh at arm dot com>]

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