[Also sent to Roland and to bug-hurd.]
Hello!
Using `-fstack-protector' with GCC 4.1 made it include assembler code
using ``%gs:0x14'' even with `-ffreestanding'. However, this isn't the
correct thing to do on a) GNU/Hurd user space and neither b) in kernel
space (with `-ffreestanding'). I think I've now tracked where this is
coming from. This is not an issue anymore with GCC 4.2 or a GCC 4.1 that
is recent enough, but there is another problem, so read on.
> > For your information, this is where the ``%gs:0x14'' was coming from, I
> > guess:
> >
> > [glibc]/elf/stackguard-macros.h
> > #v+
> > #include <stdint.h>
> >
> > #ifdef __i386__
> > # define STACK_CHK_GUARD \
> > ({ uintptr_t x; asm ("movl %%gs:0x14, %0" : "=r" (x)); x; })
> > [...]
> > #v-
It might also stem from the following, `TARGET_THREAD_SSP_OFFSET' may be
defined to ``0x14'', see below.
[GCC]/gcc/config/i386/i386.md
#v+
[...]
#ifdef TARGET_THREAD_SSP_OFFSET
if (TARGET_64BIT)
emit_insn (gen_stack_tls_protect_set_di (operands[0],
GEN_INT (TARGET_THREAD_SSP_OFFSET)));
else
emit_insn (gen_stack_tls_protect_set_si (operands[0],
GEN_INT (TARGET_THREAD_SSP_OFFSET)));
#else
if (TARGET_64BIT)
emit_insn (gen_stack_protect_set_di (operands[0], operands[1]));
else
emit_insn (gen_stack_protect_set_si (operands[0], operands[1]));
#endif
[...]
#v-
> Looks like, yes, but the compiler still shouldn't pull this in in
> freestanding mode...
What my note was also aiming at: `[glibc]/elf/stackguard-macros.h' is a
generically used file, but internally declares Linux-tls-specific macros.
Isn't that wrong and those should be somewhere below `sysdeps/.../linux/'
instead?
Going further, the only reason that the smashing stack protector
currently works on GNU/Hurd systems (in user space) --- I tested it
yesterday --- given the above usage of Linux tls internals is that GCC's
configure script currently does the following:
[GCC]/gcc/configure.ac
#v+
[...]
# Test for stack protector support in target C library.
case "$target" in
*-*-linux*)
AC_CACHE_CHECK(__stack_chk_fail in target GNU C library,
[...]
# glibc 2.4 and later provides __stack_chk_fail and
# either __stack_chk_guard, or TLS access to stack guard canary.
[...]
*) gcc_cv_libc_provides_ssp=no ;;
esac
if test x$gcc_cv_libc_provides_ssp = xyes; then
AC_DEFINE(TARGET_LIBC_PROVIDES_SSP, 1,
[Define if your target C library provides stack protector support])
fi
[...]
#v-
[GCC]/gcc/config/i386/linux.h
#v+
[...]
#ifdef TARGET_LIBC_PROVIDES_SSP
/* i386 glibc provides __stack_chk_guard in %gs:0x14. */
#define TARGET_THREAD_SSP_OFFSET 0x14
#endif
#v-
But then, if this was `*-*-*gnu*' instead of `*-*-linux*' in the above
configure check, I guess that the smashing stack protector wouldn't work
(and would instead make all compiled programs crash) in user space on
GNU/Hurd then, as then not `[GCC]/gcc/libgcc/''s generic code would be
used, but instead the Linux-tls-specific macros.
Do you think this analysis is correct? Then I'd install that as yet
another task on Savannah...
Roland, any comment on my posted smashing stack protector patch for GNU
Mach?
Regards,
Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
