This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Help regarding exporting global variable "stack_chk_guard" for Aarch64.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]