patchelf tests fail to pass on powerpc64

[adevress]

The patchelf "make check" tests fail to execute on linux powerpc64.

PASS: set-interpreter-short.sh
FAIL: set-interpreter-long.sh
FAIL: set-rpath.sh
FAIL: no-rpath.sh
FAIL: big-dynstr.sh
FAIL: set-rpath-library.sh
PASS: soname.sh

This is a blocking issue for the usage of Nix/NixOS on the power architecture.

[adevress]

This is not only a false positive.

It seems that patchelf corrupt binary under powerpc64 :

$ ./ls: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.21-powerpc64-unknown-linux-gnu/lib/ld64.so.1: bad ELF interpreter: Aucun fichier ou dossier de ce type

# patchelf to set the interpreter to a valid value
~/scratch/workspace/patchelf/src/patchelf --set-interpreter /gpfs/[.....]/nix/store/ng8p3bpwxlwp8dslv31dndkk4wrg79bp-bootstrap-tools/lib/ld-2.21.so ls

# retry execution
./ls
Processus arrêté

# valgrind trace 
 valgrind --tool=memcheck ./ls
==27375== Memcheck, a memory error detector
==27375== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27375== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27375== Command: ./ls
==27375== 
Inconsistency detected by ld.so: rtld.c: 1141: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
==27375== 
==27375== HEAP SUMMARY:

[adevress]

Anyone has seen something similar this before ?

[adevress]

I add you a little over trace on this when using only native system tools

# copy ls in current directory
cp /bin/ls ./
# use it
./ls 
# -> works with normal listing
# use patch elf to print interpreter
 ~/scratch/workspace/patchelf/src/patchelf --print-interpreter --debug  ./ls
/lib64/ld64.so.1
# list again
./ls 
# works
# now modify the interpreter with exactly the same value than before
 ~/scratch/workspace/patchelf/src/patchelf --set-interpreter /lib64/ld64.so.1 --debug  ./ls
patching ELF file `ls'
replacing section `.interp' with size 17
this is an executable
using replaced section `.interp'
last replaced is 1
looking at section `.interp'
first reserved offset/addr is 0x214/0x10000214
first page is 0x10000000
needed space is 536
needed space is 592
needed pages is 1
changing alignment of program header 2 from 65536 to 4096
changing alignment of program header 3 from 65536 to 4096
clearing first 4060 bytes
rewriting section `.interp' from offset 0x1200 (size 17) to offset 0x238 (size 17)
rewriting symbol table section 5

# now let's try to use ls again
./ls
# crash : Process stopped
# let's try to use the buggy ls into valgrind
valgrind --tool=memcheck ./ls
==7562== Memcheck, a memory error detector
==7562== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7562== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7562== Command: ./ls
==7562== 
==7562== 
==7562== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==7562==  Access not within mapped region at address 0x0
==7562==    at 0x8082267C9C: dl_main (in /lib64/ld-2.12.so)
==7562==    by 0x80822811F7: _dl_sysdep_start (in /lib64/ld-2.12.so)
==7562==    by 0x8082265E43: _dl_start_final (in /lib64/ld-2.12.so)
==7562==    by 0x808226612B: _dl_start (in /lib64/ld-2.12.so)
==7562==    by 0x80822654EF: _start (in /lib64/ld-2.12.so)
==7562==  If you believe this happened as a result of a stack
==7562==  overflow in your program's main thread (unlikely but
==7562==  possible), you can try to increase the size of the
==7562==  main thread stack using the --main-stacksize= flag.
==7562==  The main thread stack size used in this run was 10485760.
==7562== 

[adevress]

From the previous trace, it --set-interpreter seems to be broken for powerpc64.

[vcunat]

I see the code does try to be correct with endian issues, but has it ever been tested on a big-endian HW? There could be a bug in the handling (or introduced since last testing).

[adevress]

From the previous trace,

Here you have :
The readelf output before patching

http://pastebin.com/6V0gc6Wk

The readelf output after patching

http://pastebin.com/G65vnemV

and here is the diff between both.

http://pastebin.com/XaQTACx7

[adevress]

@vcunat

Notes in the project says it has been tested on powerpc 32 bits which is big endian. But I do'nt think any tests has been executed on powerpc64.

[adevress]

I just did the same test than before but using 32-bits ELF binaries. It works perfectly on PPC 32 bits.

The problem is triggered only in PPC 64 bits.

[adevress]

I found the issue.

Powerpc64 kernels can have a page size up to 65K.
This is the case here.

The Patchelf should use sysconf(_SC_PAGE_SIZE) when available to detect the kernel page size.

I'm going to make a patch for this.

[adevress]

Patch provided with #54

[adevress]

Solved with #54