Re: Is PIE randomization breaking klibc binaries?

H. Peter Anvin
2007-08-02T19:11:33Z

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