Re: Is PIE randomization breaking klibc binaries?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sergey Vlasov wrote:

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

Yup... it should probably be pointed out the reason the old kernel worked was nothing but pure dumb luck. This was a GNU ld change which needed to be undone for klibc. It's unfortunate that stock x86-64 binaries leave as little of a null pointer range as they do, but that's life, unfortunately. The other alternative is to map klibc just below the 2 GB point, which would also work, but the old way broke when the ld change went in. As previously stated, klibc-1.4.35 or higher fixes this.

	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux