0005414: uClibc segfaults in isatty for x86_64 native build (not cross)

BusyBox Bug and Patch Tracking

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0005414

[uClibc] Architecture Specific

crash

always

10-14-08 04:40

Reporter

chrisz

View Status

public

Assigned To

uClibc

Priority

normal

Resolution

open

Status

assigned

Product Version

0.9.30

Summary

0005414: uClibc segfaults in isatty for x86_64 native build (not cross)

Description

I am not 100% sure what is happening here, but I am hoping the developers on this list can help me understand. This is related to stack_chk_guard functionality.

Building uClibc for x86_64 from a gcc cross compiler configured with --disable-libssp and --disable-threads appears to work fine. It compiles libc/termios/isatty.c as follows:

__GI_isatty:
.LFB2:
       subq $88, %rsp
.LCFI0:
       movq %rsp, %rsi
       movq __stack_chk_guard(%rip), %rax <== This line is no problem
       movq %rax, 72(%rsp)
       xorl %eax, %eax
       call __GI_tcgetattr
       testl %eax, %eax
       sete %al
       movq 72(%rsp), %rdx
...

However, after building a native compiler on the uClibc system (this time including libssp and threads), and recompiling uClibc, I get the following from isatty.c:

__GI_isatty:
.LFB2:
       subq $88, %rsp
.LCFI0:
       movq %rsp, %rsi
       movq %fs:40, %rax <=== Segmentation fault occurs here
       movq %rax, 72(%rsp)
       xorl %eax, %eax
       call __GI_tcgetattr
       testl %eax, %eax
       sete %al
       movq 72(%rsp), %rdx
...

I chased this bug for a while, and found the following comment in the GCC 4.3.2 source code (gcc-4.3.2/gcc/config/i386/linux64.h : line 106)

#ifdef TARGET_LIBC_PROVIDES_SSP
/* i386 glibc provides __stack_chk_guard in %gs:0x14,
  x86_64 glibc provides it in %fs:0x28. */
#define TARGET_THREAD_SSP_OFFSET (TARGET_64BIT ? 0x28 : 0x14)
#endif

Apparently, GCC expects the C library to have placed the value of __stack_chk_guard at the location of FS register plus 40. In the case I cite above, fs has not been setup, as its value is 0, and leads to a segmentation fault. This occurs very early and affects both static and shared versions of the library:

Program received signal SIGSEGV, Segmentation fault.
*__GI_isatty (fd=0) at libc/termios/isatty.c:27
27 {
(gdb) where
0 *__GI_isatty (fd=0) at libc/termios/isatty.c:27
0000001 0x000000000041a4d3 in _stdio_init () at libc/stdio/_stdio.c:256
2 0x0000000000427473 in *__GI___uClibc_init ()
    at libc/misc/internals/__uClibc_main.c:233
0000003 0x0000000000427609 in __uClibc_main (main=0x401920 <main>, argc=1,
    argv=0x7fffb3ce0928, app_init=0x4000e8 <_init>, app_fini=0x42f6a8 <_fini>,
    rtld_fini=0, stack_end=0x7fffb3ce0918)
    at libc/misc/internals/__uClibc_main.c:318
0000004 0x0000000000400129 in _start () at libc/sysdeps/linux/x86_64/crt1.S:128
(gdb) info register rip fs
rip 0x41eaaf 0x41eaaf <*__GI_isatty+11>
fs 0x0 0
(gdb) disassemble 0x41eaaf
...
0x000000000041eaaf <*__GI_isatty+11>: mov %fs:0x28,%rax
...

This is well beyond my current abilities. Before I spend weeks trying to understand what is really happening here, can someone who understands the thread local storage models and stack protector functionality give me a hint at what might be going on, and what I should do to correct this problem?

Any help is appreciated.

Best Regards,

Chris

Additional Information

Attached Files

Relationships

There are no notes attached to this issue.

Issue History
Date Modified	Username	Field	Change
10-14-08 04:40	chrisz	New Issue
10-14-08 04:40	chrisz	Status	new => assigned
10-14-08 04:40	chrisz	Assigned To	=> uClibc