Re: Is PIE randomization breaking klibc binaries?
On Thu, 2 Aug 2007, H. Peter Anvin wrote: > 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. Thanks for pointing this out. So it seems that maybe the mainline revert of pie-randomization.patch was a little bit premature. Bret -- could you please clarify whether you have experienced also klibc-related segfaults with pie-randomization.patch applied, or you have had just random binaries segfaulting, as you pointed out here: http://lkml.org/lkml/2007/7/21/31 Seems like you are also using ubuntu, same as Ulrich, so you might have been hitting the very same behavior of klibc-1.4. Thanks in advance for clarifying this, so that I can eventually resubmit the pie-randomization patch. Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
H. Peter Anvin wrote: > 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 Just for the record: The kernel with the PIE patch boots perfectly using the klibc 1.5 shared binaries on my machine. -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
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 0x0102: > EXEC_P, D_PAGED > start address 0x0040014c > > Program Header: > PHDR off0x0040 vaddr 0x00400040 paddr > 0x00400040 align 2**3 > filesz 0x00e0 memsz 0x00e0 flags r-x > INTERP off0x0120 vaddr 0x00400120 paddr > 0x00400120 align 2**0 > filesz 0x002a memsz 0x002a flags r-- > LOAD off0x vaddr 0x0040 paddr > 0x0040 align 2**21 > filesz 0x01c3 memsz 0x01c3 flags r-x >STACK off0x vaddr 0x paddr > 0x align 2**3 > filesz 0x memsz 0x flags rwx > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .interp 002a 00400120 00400120 0120 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 1 .text 0059 0040014c 0040014c 014c 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 2 .rodata 001e 004001a5 004001a5 01a5 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .gnu_debuglink 000c 01c3 > 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 0x0102: > EXEC_P, D_PAGED > start address 0x00200200 > > Program Header: > LOAD off0x vaddr 0x0020 paddr > 0x0020 align 2**21 > filesz 0x0001197e memsz 0x0001197e flags r-x > LOAD off0x00011980 vaddr 0x00411980 paddr > 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. 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=0x10" 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 0x0100 memsz 0x4288 flags rw- >STACK off0x vaddr 0x paddr > 0x align 2**3 > filesz 0x memsz 0x flags rwx > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text da94 00200200 00200200 0200 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .data 0100 00411980 00411980 00011980 2**5 > CONTENTS, ALLOC, LOAD, DATA > 3 .bss 4188 00411a80 00411a80 00011a80 2**5 > ALLOC > 4 .gnu_debuglink 002c 00011a80 > 2**0 > CONTENTS, READONLY > SYMBOL TABLE: > no symbols > pgpK6wcG8x976.pgp Description: PGP signature
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: > 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 0x0102: > > EXEC_P, D_PAGED > > start address 0x0040014c > > > > Program Header: > > PHDR off0x0040 vaddr 0x00400040 paddr > > 0x00400040 align 2**3 > > filesz 0x00e0 memsz 0x00e0 flags r-x > > INTERP off0x0120 vaddr 0x00400120 paddr > > 0x00400120 align 2**0 > > filesz 0x002a memsz 0x002a flags r-- > > LOAD off0x vaddr 0x0040 paddr > > 0x0040 align 2**21 > > filesz 0x01c3 memsz 0x01c3 flags r-x > >STACK off0x vaddr 0x paddr > > 0x align 2**3 > > filesz 0x memsz 0x flags rwx > > > > Sections: > > Idx Name Size VMA LMA File off > > Algn > > 0 .interp 002a 00400120 00400120 0120 > > 2**0 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 1 .text 0059 0040014c 0040014c 014c > > 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, CODE > > 2 .rodata 001e 004001a5 004001a5 01a5 > > 2**0 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 3 .gnu_debuglink 000c 01c3 > > 2**0 > > CONTENTS, READONLY > > SYMBOL TABLE: > > no symbols > > > > > > $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so > >. What version of klibc is this? I think you found it: 1.4.30-3ubuntu2. > > > > > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 > > lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so > > architecture: i386:x86-64, flags 0x0102: > > EXEC_P, D_PAGED > > start address 0x00200200 > > > > Program Header: > > LOAD off0x vaddr 0x0020 paddr > > 0x0020 align 2**21 > > filesz 0x0001197e memsz 0x0001197e flags r-x > > LOAD off0x00011980 vaddr 0x00411980 paddr > > 0x00411980 align 2**21 > > Note that the vaddr here can overlap the binary which is linked starting > at 0x40. > > 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=0x10" > 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 0x0100 memsz 0x4288 flags rw- > >STACK off0x vaddr 0x paddr > > 0x align 2**3 > > filesz 0x memsz 0x flags rwx > > > > Sections: > > Idx Name Size VMA LMA File off > > Algn > > 0 .text da94 00200200 00200200 0200 > > 2**2 > > CONTENTS, ALLOC, LOAD, READONLY, CODE > > 1 .rodata 3cde 0020dca0 0020dca0 dca0 > > 2**5 > > CONTENTS, ALLOC, LOAD, READONLY, DATA > > 2 .data 0100 00411980 00411980 00011980 > > 2**5 > > CONTENTS, ALLOC, LOAD, DATA > > 3 .bss 4188 00411a80 00411a80 00011a80 > > 2**5 > > ALLOC > > 4 .gnu_debuglink 002c 00011a80 > > 2**0 > > CONTENTS, READONLY > > SYMBOL TABLE: > > no symbols > > -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. 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=0x10" 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 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 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/
Re: Is PIE randomization breaking klibc binaries?
On 8/2/07, Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Thu, 2 Aug 2007, Ulrich Kunitz wrote: > > > Here is the .config file. I used it directly with 60bfba7e8 and could > > reproduce the bug. (All other builds after the patch could also > > reproduce the bug.) > > Thanks, I used your .config against 60bfba7e8 on x86_64, and still can't > seem to be able to reproduce the problem: > > linux-w027:~ # echo "test" | ./klibc-1.5/usr/utils/shared/cat > test > linux-w027:~ # echo "test" | ./klibc-1.5/usr/utils/static/cat > test > > hpa, were you successful reproducing this? > > Bret, I can see that you also reported some related segfaults, what were > your conditions that triggered it please? not really much to it just did the usual make oldconfig on a current git and installed it with ubuntus kernel tools and it was broken the system is a 64bit feisty setup nothing special to me at least i can attach the .config later (not near the computer and its not on atm) > -- > Jiri Kosina > SUSE Labs > - 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/
Re: Is PIE randomization breaking klibc binaries?
On Thu, 2 Aug 2007, Ulrich Kunitz wrote: > Here is the .config file. I used it directly with 60bfba7e8 and could > reproduce the bug. (All other builds after the patch could also > reproduce the bug.) Thanks, I used your .config against 60bfba7e8 on x86_64, and still can't seem to be able to reproduce the problem: linux-w027:~ # echo "test" | ./klibc-1.5/usr/utils/shared/cat test linux-w027:~ # echo "test" | ./klibc-1.5/usr/utils/static/cat test hpa, were you successful reproducing this? Bret, I can see that you also reported some related segfaults, what were your conditions that triggered it please? -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
On Thu, 2 Aug 2007, Ulrich Kunitz wrote: Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) Thanks, I used your .config against 60bfba7e8 on x86_64, and still can't seem to be able to reproduce the problem: linux-w027:~ # echo test | ./klibc-1.5/usr/utils/shared/cat test linux-w027:~ # echo test | ./klibc-1.5/usr/utils/static/cat test hpa, were you successful reproducing this? Bret, I can see that you also reported some related segfaults, what were your conditions that triggered it please? -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
On 8/2/07, Jiri Kosina [EMAIL PROTECTED] wrote: On Thu, 2 Aug 2007, Ulrich Kunitz wrote: Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) Thanks, I used your .config against 60bfba7e8 on x86_64, and still can't seem to be able to reproduce the problem: linux-w027:~ # echo test | ./klibc-1.5/usr/utils/shared/cat test linux-w027:~ # echo test | ./klibc-1.5/usr/utils/static/cat test hpa, were you successful reproducing this? Bret, I can see that you also reported some related segfaults, what were your conditions that triggered it please? not really much to it just did the usual make oldconfig on a current git and installed it with ubuntus kernel tools and it was broken the system is a 64bit feisty setup nothing special to me at least i can attach the .config later (not near the computer and its not on atm) -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: 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 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols $ objdump -x lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so . What version of klibc is this? I think you found it: 1.4.30-3ubuntu2. lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so: file format elf64-x86-64 lib/klibc-7q-hWrI8UIRMp59zIo378Yl2X7A.so architecture: i386:x86-64, flags 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. 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=0x10 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 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
Sergey Vlasov wrote: Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. 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=0x10 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 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 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/
Re: Is PIE randomization breaking klibc binaries?
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 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 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 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 Note that the vaddr here can overlap the binary which is linked starting at 0x40. 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=0x10 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 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols pgpK6wcG8x976.pgp Description: PGP signature
Re: Is PIE randomization breaking klibc binaries?
H. Peter Anvin wrote: 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 Just for the record: The kernel with the PIE patch boots perfectly using the klibc 1.5 shared binaries on my machine. -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
On Thu, 2 Aug 2007, H. Peter Anvin wrote: 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. Thanks for pointing this out. So it seems that maybe the mainline revert of pie-randomization.patch was a little bit premature. Bret -- could you please clarify whether you have experienced also klibc-related segfaults with pie-randomization.patch applied, or you have had just random binaries segfaulting, as you pointed out here: http://lkml.org/lkml/2007/7/21/31 Seems like you are also using ubuntu, same as Ulrich, so you might have been hitting the very same behavior of klibc-1.4. Thanks in advance for clarifying this, so that I can eventually resubmit the pie-randomization patch. Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: > On Tue, 31 Jul 2007, H. Peter Anvin wrote: > > > > So it seems to me that either it is something x86_64 specific or > > > initramfs-specific. Will try to reproduce it. > > My guess would be the former, rather than the latter. I haven't had a > > chance to reproduce it myself yet (I'm on the road), but I will try to > > get the time tomorrow. > > I still wasn't successful reproducing it with 2.6.23-rc1 + > pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs > from 'shared' and 'static' seem to be running well. > > Ulrich, could you please send me your .config? Thanks, Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) I use klibc-utils 1.4.30-3ubuntu2 which depends on libklibc with the same version number. The processor is an Intel Core 2 Duo T5500 @ 1.66 GHz, if that helps. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Wed Jul 25 07:48:18 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-pie" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set
Re: Is PIE randomization breaking klibc binaries?
On Tue, 31 Jul 2007, H. Peter Anvin wrote: > > So it seems to me that either it is something x86_64 specific or > > initramfs-specific. Will try to reproduce it. > My guess would be the former, rather than the latter. I haven't had a > chance to reproduce it myself yet (I'm on the road), but I will try to > get the time tomorrow. I still wasn't successful reproducing it with 2.6.23-rc1 + pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs from 'shared' and 'static' seem to be running well. Ulrich, could you please send me your .config? Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
On Tue, 31 Jul 2007, H. Peter Anvin wrote: So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. My guess would be the former, rather than the latter. I haven't had a chance to reproduce it myself yet (I'm on the road), but I will try to get the time tomorrow. I still wasn't successful reproducing it with 2.6.23-rc1 + pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs from 'shared' and 'static' seem to be running well. Ulrich, could you please send me your .config? Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: On Tue, 31 Jul 2007, H. Peter Anvin wrote: So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. My guess would be the former, rather than the latter. I haven't had a chance to reproduce it myself yet (I'm on the road), but I will try to get the time tomorrow. I still wasn't successful reproducing it with 2.6.23-rc1 + pie-randomization.patch with klibc-1.5 on x86_64 system -- all programs from 'shared' and 'static' seem to be running well. Ulrich, could you please send me your .config? Thanks, Here is the .config file. I used it directly with 60bfba7e8 and could reproduce the bug. (All other builds after the patch could also reproduce the bug.) I use klibc-utils 1.4.30-3ubuntu2 which depends on libklibc with the same version number. The processor is an Intel Core 2 Duo T5500 @ 1.66 GHz, if that helps. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Wed Jul 25 07:48:18 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-pie # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_VIRT_TO_BUS=y CONFIG_NR_CPUS=2 CONFIG_PHYSICAL_ALIGN=0x20 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_K8_NB=y
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: On Tue, 31 Jul 2007, H. Peter Anvin wrote: I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. What about shared binaries? Works for me too on the pie-randomization patched kernel. So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. My guess would be the former, rather than the latter. I haven't had a chance to reproduce it myself yet (I'm on the road), but I will try to get the time tomorrow. - 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/
Re: Is PIE randomization breaking klibc binaries?
On Tue, 31 Jul 2007, H. Peter Anvin wrote: > > I just now quickly tried to with klibc-1.5 on i386 with the > > PIE-randomization patched kernel, and it seems to load static > > libraries fine. I just downloaded klibc-1.5, built it, and executed a > > few of the programs in usr/utils/static, all of them worked. Does this > > also work for you and you are experiencing the problems solely when > > the binaries are being run from initramfs during boot? I will test > > more shortly (on x86_64, directly from initramfs) in order to > > reproduce. > What about shared binaries? Works for me too on the pie-randomization patched kernel. So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: Hi Ulrich, I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. What about shared binaries? -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/
Re: Is PIE randomization breaking klibc binaries?
On Wed, 25 Jul 2007, Ulrich Kunitz wrote: > The message looks like: > sleep[7888]: segfault at 0004001C rip 0004001C rsp > 7fff14776468 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. Hi Ulrich, I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
On Wed, 25 Jul 2007, Ulrich Kunitz wrote: The message looks like: sleep[7888]: segfault at 0004001C rip 0004001C rsp 7fff14776468 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. Hi Ulrich, I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. Thanks, -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: Hi Ulrich, I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. What about shared binaries? -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/
Re: Is PIE randomization breaking klibc binaries?
On Tue, 31 Jul 2007, H. Peter Anvin wrote: I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. What about shared binaries? Works for me too on the pie-randomization patched kernel. So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. -- Jiri Kosina SUSE Labs - 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/
Re: Is PIE randomization breaking klibc binaries?
Jiri Kosina wrote: On Tue, 31 Jul 2007, H. Peter Anvin wrote: I just now quickly tried to with klibc-1.5 on i386 with the PIE-randomization patched kernel, and it seems to load static libraries fine. I just downloaded klibc-1.5, built it, and executed a few of the programs in usr/utils/static, all of them worked. Does this also work for you and you are experiencing the problems solely when the binaries are being run from initramfs during boot? I will test more shortly (on x86_64, directly from initramfs) in order to reproduce. What about shared binaries? Works for me too on the pie-randomization patched kernel. So it seems to me that either it is something x86_64 specific or initramfs-specific. Will try to reproduce it. My guess would be the former, rather than the latter. I haven't had a chance to reproduce it myself yet (I'm on the road), but I will try to get the time tomorrow. - 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/
Re: Is PIE randomization breaking klibc binaries?
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 0004001C rip 0004001C rsp 7fff14776468 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 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 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 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
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 0004001C rip 0004001C rsp 7fff14776468 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 0x0102: EXEC_P, D_PAGED start address 0x0040014c Program Header: PHDR off0x0040 vaddr 0x00400040 paddr 0x00400040 align 2**3 filesz 0x00e0 memsz 0x00e0 flags r-x INTERP off0x0120 vaddr 0x00400120 paddr 0x00400120 align 2**0 filesz 0x002a memsz 0x002a flags r-- LOAD off0x vaddr 0x0040 paddr 0x0040 align 2**21 filesz 0x01c3 memsz 0x01c3 flags r-x STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .interp 002a 00400120 00400120 0120 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 0059 0040014c 0040014c 014c 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 001e 004001a5 004001a5 01a5 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu_debuglink 000c 01c3 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 0x0102: EXEC_P, D_PAGED start address 0x00200200 Program Header: LOAD off0x vaddr 0x0020 paddr 0x0020 align 2**21 filesz 0x0001197e memsz 0x0001197e flags r-x LOAD off0x00011980 vaddr 0x00411980 paddr 0x00411980 align 2**21 filesz 0x0100 memsz 0x4288 flags rw- STACK off0x vaddr 0x paddr 0x align 2**3 filesz 0x memsz 0x flags rwx Sections: Idx Name Size VMA LMA File off Algn 0 .text da94 00200200 00200200 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 3cde 0020dca0 0020dca0 dca0 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 0100 00411980 00411980 00011980 2**5 CONTENTS, ALLOC, LOAD, DATA 3 .bss 4188 00411a80 00411a80 00011a80 2**5 ALLOC 4 .gnu_debuglink 002c 00011a80 2**0 CONTENTS, READONLY SYMBOL TABLE: no symbols -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
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 Guys, this is at boot time and most of the binaries don't work. However at the end busybox is called and then there is a shell, where I can call the binaries and force the segmentation violation. Pencil and paper work usually. But right now I don't have the broken kernel anymore and it's 1 am here. Wait for tomorrow. -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
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 - 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/
Re: Is PIE randomization breaking klibc binaries?
On 07/24/2007 06:00 PM, Ulrich Kunitz wrote:
> On 07-07-24 16:57 Chuck Ebbert wrote:
>
>>> $ strace ./cat
>>> execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
>>> directory)
>>> ...
>
> Chuck, my binaries run always into a segmentation violation. So
> ENOENT is not the issue. (Notify it was on an x86-64.)
>
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?
-
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/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 16:57 Chuck Ebbert wrote:
> > $ strace ./cat
> > execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
> > directory)
> > ...
Chuck, my binaries run always into a segmentation violation. So
ENOENT is not the issue. (Notify it was on an x86-64.)
> > $ file cat
> > cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
> > linked (uses shared libs), stripped
> >
> > Funny nobody noticed that before...
> >
>
> After installing klibc.so and klibc-.so into /lib everything works:
>
> Program Headers:
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4
> INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1
> [Requesting program interpreter:
> /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so]
>
Yes, these files were present in the initrd.img file. I checked it
by unpacking the initrd.img file. Notify also that I used
git-bisect to identify the PIE patch. This requires successful
builds. Reverting the patch clearly resolved the issue at the end.
> Ulrich, did your initrd contain the correct .so?
Sure! I have only one klibc-*.so on my box in /lib. I diffed the
file in the unpacked initrd.img with the file in /lib and there
has been no difference.
I always recreate the initial ramdisk after the kernel rebuild
with make install and my own installkernel script, which uses
mkinitramfs. The mkinitramfs script ensures that the klibc so
object from /lib and the klibc binaries from /usr/lib/klibc/bin
are copied into the initrd image. Usually that works without any
issue on x86, x86-64. PPC can't use make install, but I use
mkinitramfs there too, which handles klibc the same way.
> Did you try rebuilding klibc after building the new kernel?
Rebuilding klibc doesn't make sense from my point of view. What
should be the point of it?
--
Uli Kunitz
-
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/
Re: Is PIE randomization breaking klibc binaries?
On 07/24/2007 04:34 PM, Chuck Ebbert wrote:
> On 07/20/2007 06:05 PM, H. Peter Anvin wrote:
>>> It looks like that the PIE randomization patch breaks klibc
>>> binaries on x86-64.
>>>
>> Interesting.
>>
>> klibc binaries are indeed statically linked, but composed of two
>> different ELF images: the application itself and the shared libary
>> (which is referenced from the application header as the "interpreter").
>> Neither of these is an ET_DYN file; they are both ET_EXEC, so it
>> *should* be unaffected by the PIE randomization patch. Obviously, that
>> seems to not be the case.
>>
>> My guess is that this patch mishandles interpreter images which are
>> ET_EXEC. Jan, any insight?
>
> Well, they don't run on Fedora 6 either (which has the same code, it's
> part of exec-shield):
>
> $ strace ./cat
> execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
> directory)
> ...
> $ file cat
> cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
> linked (uses shared libs), stripped
>
> Funny nobody noticed that before...
>
After installing klibc.so and klibc-.so into /lib everything works:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4
INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1
[Requesting program interpreter:
/lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so]
Ulrich, did your initrd contain the correct .so? Did you try rebuilding klibc
after
building the new kernel?
-
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/
Re: Is PIE randomization breaking klibc binaries?
On 07/20/2007 06:05 PM, H. Peter Anvin wrote:
>> It looks like that the PIE randomization patch breaks klibc
>> binaries on x86-64.
>>
>
> Interesting.
>
> klibc binaries are indeed statically linked, but composed of two
> different ELF images: the application itself and the shared libary
> (which is referenced from the application header as the "interpreter").
> Neither of these is an ET_DYN file; they are both ET_EXEC, so it
> *should* be unaffected by the PIE randomization patch. Obviously, that
> seems to not be the case.
>
> My guess is that this patch mishandles interpreter images which are
> ET_EXEC. Jan, any insight?
Well, they don't run on Fedora 6 either (which has the same code, it's
part of exec-shield):
$ strace ./cat
execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or
directory)
...
$ file cat
cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically
linked (uses shared libs), stripped
Funny nobody noticed that before...
-
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/
Re: Is PIE randomization breaking klibc binaries?
On 07/20/2007 06:05 PM, H. Peter Anvin wrote: It looks like that the PIE randomization patch breaks klibc binaries on x86-64. Interesting. klibc binaries are indeed statically linked, but composed of two different ELF images: the application itself and the shared libary (which is referenced from the application header as the interpreter). Neither of these is an ET_DYN file; they are both ET_EXEC, so it *should* be unaffected by the PIE randomization patch. Obviously, that seems to not be the case. My guess is that this patch mishandles interpreter images which are ET_EXEC. Jan, any insight? Well, they don't run on Fedora 6 either (which has the same code, it's part of exec-shield): $ strace ./cat execve(./cat, [./cat], [/* 55 vars */]) = -1 ENOENT (No such file or directory) ... $ file cat cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped Funny nobody noticed that before... - 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/
Re: Is PIE randomization breaking klibc binaries?
On 07/24/2007 04:34 PM, Chuck Ebbert wrote: On 07/20/2007 06:05 PM, H. Peter Anvin wrote: It looks like that the PIE randomization patch breaks klibc binaries on x86-64. Interesting. klibc binaries are indeed statically linked, but composed of two different ELF images: the application itself and the shared libary (which is referenced from the application header as the interpreter). Neither of these is an ET_DYN file; they are both ET_EXEC, so it *should* be unaffected by the PIE randomization patch. Obviously, that seems to not be the case. My guess is that this patch mishandles interpreter images which are ET_EXEC. Jan, any insight? Well, they don't run on Fedora 6 either (which has the same code, it's part of exec-shield): $ strace ./cat execve(./cat, [./cat], [/* 55 vars */]) = -1 ENOENT (No such file or directory) ... $ file cat cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped Funny nobody noticed that before... After installing klibc.so and klibc-ID.so into /lib everything works: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4 INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1 [Requesting program interpreter: /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so] Ulrich, did your initrd contain the correct .so? Did you try rebuilding klibc after building the new kernel? - 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/
Re: Is PIE randomization breaking klibc binaries?
On 07-07-24 16:57 Chuck Ebbert wrote: $ strace ./cat execve(./cat, [./cat], [/* 55 vars */]) = -1 ENOENT (No such file or directory) ... Chuck, my binaries run always into a segmentation violation. So ENOENT is not the issue. (Notify it was on an x86-64.) $ file cat cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped Funny nobody noticed that before... After installing klibc.so and klibc-ID.so into /lib everything works: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x34 0x08048034 0x08048034 0xa0 0xa0 R E 0x4 INTERP 0xd4 0x080480d4 0x080480d4 0x2a 0x2a R 0x1 [Requesting program interpreter: /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so] Yes, these files were present in the initrd.img file. I checked it by unpacking the initrd.img file. Notify also that I used git-bisect to identify the PIE patch. This requires successful builds. Reverting the patch clearly resolved the issue at the end. Ulrich, did your initrd contain the correct .so? Sure! I have only one klibc-*.so on my box in /lib. I diffed the file in the unpacked initrd.img with the file in /lib and there has been no difference. I always recreate the initial ramdisk after the kernel rebuild with make install and my own installkernel script, which uses mkinitramfs. The mkinitramfs script ensures that the klibc so object from /lib and the klibc binaries from /usr/lib/klibc/bin are copied into the initrd image. Usually that works without any issue on x86, x86-64. PPC can't use make install, but I use mkinitramfs there too, which handles klibc the same way. Did you try rebuilding klibc after building the new kernel? Rebuilding klibc doesn't make sense from my point of view. What should be the point of it? -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
On 07/24/2007 06:00 PM, Ulrich Kunitz wrote: On 07-07-24 16:57 Chuck Ebbert wrote: $ strace ./cat execve(./cat, [./cat], [/* 55 vars */]) = -1 ENOENT (No such file or directory) ... Chuck, my binaries run always into a segmentation violation. So ENOENT is not the issue. (Notify it was on an x86-64.) 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? - 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/
Re: Is PIE randomization breaking klibc binaries?
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 - 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/
Re: Is PIE randomization breaking klibc binaries?
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 Guys, this is at boot time and most of the binaries don't work. However at the end busybox is called and then there is a shell, where I can call the binaries and force the segmentation violation. Pencil and paper work usually. But right now I don't have the broken kernel anymore and it's 1 am here. Wait for tomorrow. -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
On Fri, 20 Jul 2007 23:02:12 -0700 "Bret Towe" <[EMAIL PROTECTED]> wrote: > On 7/20/07, Ulrich Kunitz <[EMAIL PROTECTED]> wrote: > > Since this week new linux-2.6/master kernels don't work with my > > initial ram disks. The sleep binary runs repeatingly into > > segmentation faults until the Busybox shell starts. My system is a > > x86-64 with Kubuntu Feisty Fawn. > > > > By bisecting I found out that the PIE randomization patch (commit 60bfba7e) > > appears to cause the segmentation faults. > > > > Digging further into the issue I found out, that the sleep binary > > on the initial ramdisk is a klibc binary. /usr/bin/file says it is > > statically linked and uses shared libraries. I have no clue about > > klibc, but the binaries seem to be statically linked, but load a > > shared library; probably at a fixed address. Other klibc binaries are also > > running into segmentation faults. Busybox is working, but it is > > statically linked and doesn't use a shared library. > > > > It looks like that the PIE randomization patch breaks klibc > > binaries on x86-64. > > > > -- > > Uli Kunitz > > - > > oh bugger I just spent a few hours bisecting to find this headache > only to find someone else had 8 hours ago... *sigh* > > anyhow also seeing seg faults here on a amd64 ubuntu system > reverting the PIE randomization patch made it go away (cc's added) I don't think we'll be fixing this in time for -rc1. I'll revert it. Thanks for the prompt and accurate reporting. - 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/
Re: Is PIE randomization breaking klibc binaries?
On 7/20/07, Ulrich Kunitz <[EMAIL PROTECTED]> wrote: Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - oh bugger I just spent a few hours bisecting to find this headache only to find someone else had 8 hours ago... *sigh* anyhow also seeing seg faults here on a amd64 ubuntu system reverting the PIE randomization patch made it go away - 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/
Re: Is PIE randomization breaking klibc binaries?
On 7/20/07, Ulrich Kunitz [EMAIL PROTECTED] wrote: Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - oh bugger I just spent a few hours bisecting to find this headache only to find someone else had 8 hours ago... *sigh* anyhow also seeing seg faults here on a amd64 ubuntu system reverting the PIE randomization patch made it go away - 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/
Re: Is PIE randomization breaking klibc binaries?
On Fri, 20 Jul 2007 23:02:12 -0700 Bret Towe [EMAIL PROTECTED] wrote: On 7/20/07, Ulrich Kunitz [EMAIL PROTECTED] wrote: Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - oh bugger I just spent a few hours bisecting to find this headache only to find someone else had 8 hours ago... *sigh* anyhow also seeing seg faults here on a amd64 ubuntu system reverting the PIE randomization patch made it go away (cc's added) I don't think we'll be fixing this in time for -rc1. I'll revert it. Thanks for the prompt and accurate reporting. - 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/
Re: Is PIE randomization breaking klibc binaries?
Ulrich Kunitz wrote: > Since this week new linux-2.6/master kernels don't work with my > initial ram disks. The sleep binary runs repeatingly into > segmentation faults until the Busybox shell starts. My system is a > x86-64 with Kubuntu Feisty Fawn. > > By bisecting I found out that the PIE randomization patch (commit 60bfba7e) > appears to cause the segmentation faults. > > Digging further into the issue I found out, that the sleep binary > on the initial ramdisk is a klibc binary. /usr/bin/file says it is > statically linked and uses shared libraries. I have no clue about > klibc, but the binaries seem to be statically linked, but load a > shared library; probably at a fixed address. Other klibc binaries are also > running into segmentation faults. Busybox is working, but it is > statically linked and doesn't use a shared library. > > It looks like that the PIE randomization patch breaks klibc > binaries on x86-64. > Interesting. klibc binaries are indeed statically linked, but composed of two different ELF images: the application itself and the shared libary (which is referenced from the application header as the "interpreter"). Neither of these is an ET_DYN file; they are both ET_EXEC, so it *should* be unaffected by the PIE randomization patch. Obviously, that seems to not be the case. My guess is that this patch mishandles interpreter images which are ET_EXEC. Jan, any insight? -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/
Is PIE randomization breaking klibc binaries?
Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - 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/
Is PIE randomization breaking klibc binaries?
Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. -- Uli Kunitz - 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/
Re: Is PIE randomization breaking klibc binaries?
Ulrich Kunitz wrote: Since this week new linux-2.6/master kernels don't work with my initial ram disks. The sleep binary runs repeatingly into segmentation faults until the Busybox shell starts. My system is a x86-64 with Kubuntu Feisty Fawn. By bisecting I found out that the PIE randomization patch (commit 60bfba7e) appears to cause the segmentation faults. Digging further into the issue I found out, that the sleep binary on the initial ramdisk is a klibc binary. /usr/bin/file says it is statically linked and uses shared libraries. I have no clue about klibc, but the binaries seem to be statically linked, but load a shared library; probably at a fixed address. Other klibc binaries are also running into segmentation faults. Busybox is working, but it is statically linked and doesn't use a shared library. It looks like that the PIE randomization patch breaks klibc binaries on x86-64. Interesting. klibc binaries are indeed statically linked, but composed of two different ELF images: the application itself and the shared libary (which is referenced from the application header as the interpreter). Neither of these is an ET_DYN file; they are both ET_EXEC, so it *should* be unaffected by the PIE randomization patch. Obviously, that seems to not be the case. My guess is that this patch mishandles interpreter images which are ET_EXEC. Jan, any insight? -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/
