Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 21 Jul 2015 04:50:50 +0000
From: Warren Armstrong <WA@...ntessencelabs.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: RE: Segfault in VDSO symbol resolution

Thanks for the answer - I did not see before that there's a 'musl-gcc'.  If I use that, then the dynamic
linker is set correctly and the application works as expected.


-----Original Message-----
From: Рысь [mailto:lynx@...server.ru] 
Sent: Tuesday, 21 July 2015 2:19 PM
To: musl@...ts.openwall.com
Subject: Re: [musl] Segfault in VDSO symbol resolution

On Tue, 21 Jul 2015 01:23:38 +0000
Warren Armstrong <WA@...ntessencelabs.com> wrote:

> Hi,
> 
> I've been trying to compile the latest version of OpenSSL against 
> musl.  The compilation succeeds after some manual tweaking of config 
> files but the test suite fails.  I have managed to reproduce the 
> failure using a small C program and traced the problem to a segfault 
> in __vdsosym, but I've reached the limits of my knowledge and hope 
> someone on the list can help me.  Details of my setup are below.
> 
> Cheers,
> Warren
> 
> System:
>     uname -a: Linux QLBuild01 3.16.0-qre #5 SMP Wed Jun 17 15:02:01 
> AEST 2015 x86_64 x86_64 x86_64 GNU/Linux (Note: This kernel name is 
> non-standard but it is a stock 3.16.0 kernel) /etc/issue: Ubuntu
> 14.04.1 LTS gcc version: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
> 
> Musl version:
>    Git checkout yesterday from:
> git remote show origin
> * remote origin
>   Fetch URL: git://git.musl-libc.org/musl
>   Push  URL: git://git.musl-libc.org/musl
>   HEAD branch: master
>   Remote branches:
>     master tracked
>     rs-1.0 tracked
>   Local branch configured for 'git pull':
>     master merges with remote master
>   Local ref configured for 'git push':
>     master pushes to master (up to date) Most recent commit: 
> 0f9c2666aca95eb98eb0ef4f4d8d1473c8ce3fa0
> 
> Musl configuration:
>     CFLAGS="-O0" ./configure --prefix=/usr/local/debug-musl 
> --enable-debug (The problem first arose with a standard configuration 
> specifying only --prefix - I have changed the configuration to make 
> GDB useful and the problem persists)
> 
> The test program (shell.c):
> #include <time.h>
> 
> int main()
> {
>     time(NULL);
>     return 0;
> }
> 
> Test program compilation:
> gcc -nostdlib -L /usr/local/debug-musl/lib/ -isystem 
> /usr/local/debug-musl/include/ -o shell shell.c 
> /usr/local/debug-musl/lib/crt1.o /usr/local/debug-musl/lib/crti.o -lc 
> -lgcc
> 

The gcc command line probably misses -Wl,-dynamic-linker -Wl,/path/to/musl.ld.so part

> Dynamic linkage of the test program:
> ldd ./shell
>         linux-vdso.so.1 =>  (0x00007fffc6f3d000)
>         libc.so => /usr/local/debug-musl/lib/libc.so
> (0x00007fad75dc2000)

Testing binary with glibc ldd makes no sense,

> 
> Gdb output:
> gdb ./shell
> <startup blurb removed>
> Reading symbols from ./shell...done.
> (gdb) run
> Starting program: /home/warmstrong/shell
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff7b37726 in __vdsosym (vername=0x7ffff7bd496b "LINUX_2.6",
> name=0x7ffff7bd4956 "__vdso_clock_gettime") at src/internal/vdso.c:45
> 45              for (i=0; libc.auxv[i] != AT_SYSINFO_EHDR; i+=2)
> (gdb) bt #0  0x00007ffff7b37726 in __vdsosym (vername=0x7ffff7bd496b 
> "LINUX_2.6", name=0x7ffff7bd4956 "__vdso_clock_gettime") at
> src/internal/vdso.c:45 #1  0x00007ffff7b9ec6e in __clock_gettime 
> (clk=0, ts=0x7fffffffe5b0) at src/time/clock_gettime.c:31 #2 
> 0x00007ffff7ba081d in time (t=0x0) at src/time/time.c:9 #3 
> 0x00000000004003ee in main () (gdb) frame 0 #0  0x00007ffff7b37726 in 
> __vdsosym (vername=0x7ffff7bd496b "LINUX_2.6", name=0x7ffff7bd4956
> "__vdso_clock_gettime") at src/internal/vdso.c:45 45              for
> (i=0; libc.auxv[i] != AT_SYSINFO_EHDR; i+=2) (gdb) info locals i = 0 
> eh = 0x0 ph = 0x7fffffffe610 dynv = 0x0 base = 1 strings = 
> 0x7ffff7de9557 "H\211\305d\213\004%\030"
> syms = 0x7fffffffe5d0
> hashtab = 0x0
> versym = 0x0
> verdef = 0x7fffffffe620
> (gdb) print libc.auxv
> No symbol "libc" in current context.
> 
> Readelf output:
> $: readelf -d shell
> Dynamic section at offset 0xed0 contains 14 entries:
>   Tag        Type                         Name/Value
> 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
> 0x000000000000000c (INIT)               0x4003a0
> 0x000000000000000d (FINI)               0x40041f
> 0x000000006ffffef5 (GNU_HASH)           0x400278
> 0x0000000000000005 (STRTAB)             0x400338
> 0x0000000000000006 (SYMTAB)             0x4002a8
> 0x000000000000000a (STRSZ)              56 (bytes)
> 0x000000000000000b (SYMENT)             24 (bytes)
> 0x0000000000000015 (DEBUG)              0x0
> 0x0000000000000003 (PLTGOT)             0x601000
> 0x0000000000000002 (PLTRELSZ)           48 (bytes)
> 0x0000000000000014 (PLTREL)             RELA
> 0x0000000000000017 (JMPREL)             0x400370
> 0x0000000000000000 (NULL)               0x0
> 
> $ readelf -l shell
> 
> Elf file type is EXEC (Executable file) Entry point 0x4003f5 There are 
> 9 program headers, starting at offset 64
> 
> Program Headers:
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   PHDR           0x0000000000000040 0x0000000000400040
> 0x0000000000400040 0x00000000000001f8 0x00000000000001f8  R E    8
>   INTERP         0x0000000000000238 0x0000000000400238
> 0x0000000000400238 0x000000000000001c 0x000000000000001c  R      1
>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

If your system is glibc based then why your produced binary calls glibc dynamic linker? It should call musl one (symlink to libc.so).

>   LOAD           0x0000000000000000 0x0000000000400000
> 0x0000000000400000 0x00000000000004a0 0x00000000000004a0  R E
> 200000 LOAD           0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000158 0x0000000000000158  RW
> 200000 DYNAMIC        0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000130 0x0000000000000130  RW     8
>   NOTE           0x0000000000000254 0x0000000000400254
> 0x0000000000400254 0x0000000000000024 0x0000000000000024  R      4
>   GNU_EH_FRAME   0x0000000000000420 0x0000000000400420
> 0x0000000000400420 0x000000000000001c 0x000000000000001c  R      4
>   GNU_STACK      0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000  RW     10
>   GNU_RELRO      0x0000000000000ed0 0x0000000000600ed0
> 0x0000000000600ed0 0x0000000000000130 0x0000000000000130  R      1
> 
> Section to Segment mapping:
>   Segment Sections...
>    00
>    01     .interp
>    02     .interp .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.plt .init .plt .text .fini .eh_frame_hdr .eh_frame
>    03     .dynamic .got.plt
>    04     .dynamic
>    05     .note.gnu.build-id
>    06     .eh_frame_hdr
>    07
>    08     .dynamic
> 
> $ readelf --dyn-syms shell
> 
> Symbol table '.dynsym' contains 6 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
>      1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND time
>      2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> __libc_start_main 3: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT
> 14 _edata 4: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT   14 _end
>      5: 0000000000601028     0 NOTYPE  GLOBAL DEFAULT   14 __bss_start

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.