From: Ulrich Kunitz <kune@deine-taler.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Chuck Ebbert <cebbert@redhat.com>,
linux-kernel@vger.kernel.org, honza@jikos.cz, jkosina@suse.cz
Subject: Re: Is PIE randomization breaking klibc binaries?
Date: Wed, 25 Jul 2007 08:32:43 +0200 [thread overview]
Message-ID: <20070725063243.GA25148@deine-taler.de> (raw)
In-Reply-To: <46A68118.9080902@zytor.com>
On 07-07-24 15:45 H. Peter Anvin wrote:
> Chuck Ebbert wrote:
> >
> >Okay, I tested with Fedora on x86_64 and it worked there too.
> >(Not that that proves much.)
> >
> >Did you capture any of the error messages, like the address
> >of the segfault?
> >
>
> FWIW, on x86-64, this should show up in dmesg.
>
> -hpa
Ok, I have tested it again.
The message looks like:
sleep[7888]: segfault at 000000000004001C rip 000000000004001C rsp 00007fff14776468 error 14
Repeated calls get the same message with the stack pointer
changing. Other binaries (mount) have a segmentation fault at
another addressi (0x400184). It appears that the instruction
pointer fails at the start address of the klibc binary. Notify
that this lies in the binary itself and not in the /lib/klibc*.so
object, so it appears that the klibc binary sections are loaded at
randomized addresses.
Here is some output from objdump:
$ objdump -x bin/sleep
bin/sleep: file format elf64-x86-64
bin/sleep
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x000000000040014c
Program Header:
PHDR off 0x0000000000000040 vaddr 0x0000000000400040 paddr 0x0000000000400040 align 2**3
filesz 0x00000000000000e0 memsz 0x00000000000000e0 flags r-x
INTERP off 0x0000000000000120 vaddr 0x0000000000400120 paddr 0x0000000000400120 align 2**0
filesz 0x000000000000002a memsz 0x000000000000002a flags r--
LOAD off 0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**21
filesz 0x00000000000001c3 memsz 0x00000000000001c3 flags r-x
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 0000002a 0000000000400120 0000000000400120 00000120 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00000059 000000000040014c 000000000040014c 0000014c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 0000001e 00000000004001a5 00000000004001a5 000001a5 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .gnu_debuglink 0000000c 0000000000000000 0000000000000000 000001c3 2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols
$ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so
lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64
lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000200200
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000000200000 paddr 0x0000000000200000 align 2**21
filesz 0x000000000001197e memsz 0x000000000001197e flags r-x
LOAD off 0x0000000000011980 vaddr 0x0000000000411980 paddr 0x0000000000411980 align 2**21
filesz 0x0000000000000100 memsz 0x0000000000004288 flags rw-
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000da94 0000000000200200 0000000000200200 00000200 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .rodata 00003cde 000000000020dca0 000000000020dca0 0000dca0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00000100 0000000000411980 0000000000411980 00011980 2**5
CONTENTS, ALLOC, LOAD, DATA
3 .bss 00004188 0000000000411a80 0000000000411a80 00011a80 2**5
ALLOC
4 .gnu_debuglink 0000002c 0000000000000000 0000000000000000 00011a80 2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols
--
Uli Kunitz
next prev parent reply other threads:[~2007-07-25 6:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 21:13 Is PIE randomization breaking klibc binaries? Ulrich Kunitz
2007-07-20 22:05 ` H. Peter Anvin
2007-07-24 20:34 ` Chuck Ebbert
2007-07-24 20:57 ` Chuck Ebbert
2007-07-24 22:00 ` Ulrich Kunitz
2007-07-24 22:41 ` Chuck Ebbert
2007-07-24 22:45 ` H. Peter Anvin
2007-07-24 23:13 ` Ulrich Kunitz
2007-07-25 6:32 ` Ulrich Kunitz [this message]
2007-07-31 11:30 ` Jiri Kosina
2007-07-31 12:01 ` H. Peter Anvin
2007-07-31 12:19 ` Jiri Kosina
2007-07-31 12:15 ` H. Peter Anvin
2007-08-01 14:07 ` Jiri Kosina
2007-08-02 4:29 ` Ulrich Kunitz
2007-08-02 11:21 ` Jiri Kosina
2007-08-02 17:03 ` Bret Towe
2007-08-02 19:02 ` Sergey Vlasov
2007-08-02 19:10 ` H. Peter Anvin
2007-08-02 20:42 ` Ulrich Kunitz
2007-08-02 21:03 ` Jiri Kosina
2007-08-02 19:10 ` Ulrich Kunitz
2007-07-21 6:02 ` Bret Towe
2007-07-21 10:18 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070725063243.GA25148@deine-taler.de \
--to=kune@deine-taler.de \
--cc=cebbert@redhat.com \
--cc=honza@jikos.cz \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox