This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Help regarding exporting global variable "stack_chk_guard" for Aarch64.
- From: Venkataramanan Kumar <venkataramanan dot kumar at linaro dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-help at sourceware dot org
- Date: Mon, 2 Dec 2013 12:11:11 +0530
- Subject: Help regarding exporting global variable "stack_chk_guard" for Aarch64.
- Authentication-results: sourceware.org; auth=none
Hi Joseph,
I am continuing on the topic discussed with you on GCC mailing list here.
Ref:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02555.html
----Snip-----
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).
-----Snip----
As you said when I set THREAD_SET_STACK_GUARD then "stack_chk_guard"
is not exported. So I changed the export logic by introducing a new
macro EXPORT_GLOBAL_STACK_GUARD and defined it for Aarch64.
I used that macro for exporting and setting the global
"stack_chk_guard" to coexist with the TLS based stack guard check.
-----Snip----
diff --git a/csu/libc-start.c b/csu/libc-start.c
index c898d06..7479bf8 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -32,11 +32,13 @@ extern int __libc_multiple_libcs;
#ifndef SHARED
# include <dl-osinfo.h>
extern void __pthread_initialize_minimal (void);
-# ifndef THREAD_SET_STACK_GUARD
+
+#if !defined(THREAD_SET_STACK_GUARD) || defined(EXPORT_GLOBAL_STACK_GUARD)
/* Only exported for architectures that don't store the stack guard canary
in thread local area. */
uintptr_t __stack_chk_guard attribute_relro;
-# endif
+#endif
+
# ifndef THREAD_SET_POINTER_GUARD
/* Only exported for architectures that don't store the pointer guard
value in thread local area. */
@@ -196,11 +198,13 @@ LIBC_START_MAIN (int (*main) (int, char **, char
** MAIN_AUXVEC_DECL),
/* Set up the stack checker's canary. */
uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (_dl_random);
-# ifdef THREAD_SET_STACK_GUARD
- THREAD_SET_STACK_GUARD (stack_chk_guard);
-# else
+#if !defined(THREAD_SET_STACK_GUARD) || defined(EXPORT_GLOBAL_STACK_GUARD)
__stack_chk_guard = stack_chk_guard;
-# endif
+#endif
+
+#ifdef THREAD_SET_STACK_GUARD
+ THREAD_SET_STACK_GUARD (stack_chk_guard);
+#endif
/* Set up the pointer guard value. */
uintptr_t pointer_chk_guard = _dl_setup_pointer_guard (_dl_random,
----Snip----
Now on versioning that symbol "stack_check_guard" at Glibc 2.17, When
I did objdump of the patched ld.so I am getting stack_check_guard
already versioned at glibc 2.17.
objdump -T ld.so | grep stack_chk
000000000002bdd0 g DO .data.rel.ro 0000000000000008 GLIBC_2.17
__stack_chk_guard
Should I need to add default_symbol_version and set it against GLIBC_2.17 ?
Some pointers on versioning would help me here.
regards,
Venkat.