[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %gs:0x14

From: Thomas Schwinge
Subject: Re: %gs:0x14
Date: Tue, 14 Nov 2006 16:15:08 +0100
User-agent: Mutt/1.5.6+20040907i

[Also sent to Roland and to bug-hurd.]


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.

  if (TARGET_64BIT)
    emit_insn (gen_stack_tls_protect_set_di (operands[0],
                                        GEN_INT (TARGET_THREAD_SSP_OFFSET)));
    emit_insn (gen_stack_tls_protect_set_si (operands[0],
                                        GEN_INT (TARGET_THREAD_SSP_OFFSET)));
  if (TARGET_64BIT)
    emit_insn (gen_stack_protect_set_di (operands[0], operands[1]));
    emit_insn (gen_stack_protect_set_si (operands[0], operands[1]));

> 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/'

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:

# Test for stack protector support in target C library.
case "$target" in
    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 ;;
if test x$gcc_cv_libc_provides_ssp = xyes; then
            [Define if your target C library provides stack protector support])

/* i386 glibc provides __stack_chk_guard in %gs:0x14.  */
#define TARGET_THREAD_SSP_OFFSET        0x14

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


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]