This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] [PATCH, AARCH64] Machine descriptions to support stack smashing protection
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Venkataramanan Kumar <venkataramanan dot kumar at linaro dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Richard Earnshaw <rearnsha at arm dot com>, Patch Tracking <patch at linaro dot org>
- Date: Wed, 20 Nov 2013 17:08:13 +0000
- Subject: Re: [RFC] [PATCH, AARCH64] Machine descriptions to support stack smashing protection
- Authentication-results: sourceware.org; auth=none
- References: <CAJK_mQ0kCcmwPkkPqsLszGW7rBxcCG+1Vn5KE6JXKNYj2fajXQ at mail dot gmail dot com> <20131119110656 dot GR892 at tucnak dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311191620180 dot 534 at digraph dot polyomino dot org dot uk> <CAJK_mQ1+T7Mo8M=T1HQSxxGhsMhX=3biKhD4NBYRYnoOaY3xOQ at mail dot gmail dot com>
On Wed, 20 Nov 2013, Venkataramanan Kumar wrote:
> > I would like to see a clear description of what happens with all eight
> > combinations of (glibc version does or doesn't support this, GCC building
> > glibc does or doesn't support this, GCC building user program does or
> > doesn't support this). Which of the (GCC building glibc, glibc)
> > combinations will successfully build glibc? Will all such glibcs be
> > binary-compatible? Will both old and new GCC work for building user
> > programs with both old and new glibc?
>
> Can you please clarify why we need to consider "the gcc compiler that
> builds the glibc" in the combinations you want me to describe. I am
> not able to understand that.
Let's imagine this support goes in GCC 4.9 and the glibc support goes in
glibc 2.19, whereas GCC 4.8 and glibc 2.18 are versions without this
support.
* Building glibc 2.18 with GCC 4.8 already works (I presume).
* Suppose you use GCC 4.9 to build glibc 2.18. Does this work? If it
works, it must produce a glibc binary that's ABI compatible with one built
with GCC 4.8, meaning same symbols exported at same symbol versions.
* Suppose you build glibc 2.19 with GCC 4.8. Does this work? If it does,
then it must be ABI compatible with 2.18 (meaning the symbols exported at
GLIBC_2.18 or earlier versions must be exactly the same as exported at
those versions in 2.18).
* Suppose you build glibc 2.19 with GCC 4.9. This needs to work and must
again produce a binary compatible with the previous ones.
Note: there is no current glibc support for architectures that gained
TLS-based stack guards after 2.4 (meaning they need both a TLS-based
scheme and backwards compatibility for binaries using __stack_chk_guard),
and your glibc patch doesn't seem to add any. It looks to me like your
glibc patch would have removed the __stack_chk_guard symbol and so failed
ABI tests (this symbol being defined only if THREAD_SET_STACK_GUARD isn't
defined) - you didn't make clear if your patch was tested with the glibc
testsuite including passing the ABI tests. The normal presumption is that
it's not acceptable to remove exported symbols from glibc as some
application might be using them.
You need to ensure that, when new glibc is built, whatever compiler it's
built with, it continues to export the __stack_chk_guard symbol at version
GLIBC_2.17. Furthermore, if any released GCC version would generate
references to __stack_chk_guard when compiling code for AArch64 with stack
protection, you need to ensure __stack_chk_guard is a normal symbol not a
compat symbol so that people can continue to link against new glibc when
using old GCC. If it's only a limited range of development versions of
GCC that could have generated code using __stack_chk_guard because
released versions didn't support stack protection on AArch64 at all, a
compat symbol would probably be OK (but you should still ensure that the
variable gets initialized with the correct value for any applications
built with those development versions of GCC).
--
Joseph S. Myers
joseph@codesourcery.com