public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Vlasov <vsu@altlinux.ru>
To: Ulrich Kunitz <kune@deine-taler.de>
Cc: Chuck Ebbert <cebbert@redhat.com>,
	linux-kernel@vger.kernel.org, honza@jikos.cz, jkosina@suse.cz,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Is PIE randomization breaking klibc binaries?
Date: Thu, 2 Aug 2007 23:02:19 +0400	[thread overview]
Message-ID: <20070802230219.97b7f7b5.vsu@altlinux.ru> (raw)
In-Reply-To: <20070725063243.GA25148@deine-taler.de>

[-- Attachment #1: Type: text/plain, Size: 3958 bytes --]

On Wed, 25 Jul 2007 08:32:43 +0200 Ulrich Kunitz wrote:

[...]
> 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

What version of klibc is this?

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

Note that the vaddr here can overlap the binary which is linked starting
at 0x400000.

This is the bug which I have found and fixed some time ago:

http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10df6dfb13ffefe716f12136bbc667f18ff64744

The fix was included in klibc-1.4.35, but does not seem to be applied in
your case (the alignment is still 2**21 - it should be 2**20) - so
either you are using an old klibc, or the "-z max-page-size=0x100000"
option does not take effect for some reason.

In my case the buggy klibc worked fine with a stock 2.6.18 kernel, but
broke when the execshield patch was applied - and the commit 60bfba7e
code comes from execshield, so it looks like the same problem.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-08-02 19:23 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
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 [this message]
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=20070802230219.97b7f7b5.vsu@altlinux.ru \
    --to=vsu@altlinux.ru \
    --cc=cebbert@redhat.com \
    --cc=honza@jikos.cz \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=kune@deine-taler.de \
    --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