Date: Fri, 1 Aug 2014 05:39:55 -0000 From: weimingz@...eaurora.org To: dalias@...c.org Cc: musl@...ts.openwall.com Subject: RE: static PIE Hi Rich, Glad to let you know that, with your new method, my ARMv7 version of static linked PIE works well under ARM-based linux. Thanks again! Weiming > PS: I also dump the personality via printf("%x", personality(0xffffffff)) > and AT_BASE (got from elfAuxVec from stack) inside the test program. > AT_BASE is always 0, and personality is 0xC0 0000 ( > READ_IMPLIES_EXEC = 0x0400000 | ADDR_LIMIT_32BIT = 0x0800000) > > When I run the regular PIE executable (plain compiled with -fpie -pie), > AT_BASE changes every run. And personality is 0x800000 > > > -----Original Message----- > From: Weiming Zhao [mailto:weimingz@...eaurora.org] > Sent: Wednesday, July 30, 2014 4:28 PM > To: musl@...ts.openwall.com > Subject: RE: [musl] static PIE > > Hi Rich, > > Thanks for the new method. I'll try it. > With the old method "-static -pie", "readelf -r" shows R_ARM_RELATIVE > entries for the executable. "readelf -S" also lists .dynamic, .rel.dyn > sections. > "file test" shows "ELF 32-bit LSB shared object, ARM, version 1 (SYSV), > dynamically linked, not stripped". > So it looks a correct PIE file. > > But I can just run it even without calling _static_pie_reloc. (I linked it > against *.lo and unchanged crt1.o in MUSL lib). Is that expected? > > That makes me feel that ld already fills the right data for those > relocation entries > > Another question: "-nostartfiles" makes some difference. Without it, the > executable can be run on both real ARM-based linux and QEMU. But with it, > it can only run on real Linux. QEMU will report "Invalud argument" error. > Do you know why? > > Thanks! > Weiming > > > -----Original Message----- > From: 'Rich Felker' [mailto:dalias@...ifal.cx] > Sent: Wednesday, July 30, 2014 1:27 PM > To: Weiming Zhao > Cc: musl@...ts.openwall.com > Subject: Re: [musl] static PIE > > On Wed, Jul 30, 2014 at 12:19:03PM -0700, Weiming Zhao wrote: >> I just find a very interesting article written by you: >> >> http://www.openwall.com/lists/musl/2012/05/24/1 > > This method is somewhat outdated. In particular, requiring a custom linker > script is a pain. > > The new method is to use -shared instead of -pie to trick gcc that it's > generating a shared library (this will cause it to use a linker mode that > does not add a PT_INTERP header, and to omit crt1) and manually add the > needed Zcrt.o (no need to use -nostartfiles to suppress others). The > command line should look like: > > gcc -shared -static-libgcc -Wl,-static -Wl,-Bsymbolic \ > Zcrt1.o Zcrt2.o [your object files...] > >> I want to do the similar thing on ARM linux. I see _static_pie_reloc >> does the relocation, which would be done by loader in dynamic PIE. > > Nice! Are you interested in trying to get this 'upstream' in gcc? > Technically it's not needed, but it would be nice if "-pie -static" > just did the right thing without the command line hackery. > >> But with "-static", those reloc entries has already been fixed by ld. >> Without that, my code can still run but at fixed address space. > > I don't think that should happen. Static linking objects (as long as > they're > PIC/PIE) into a ET_DYN ELF file (.so or PIE executable) should not result > in fixed addresses but "relative" type relocations for the dynamic linker. > >> To get the benefit of PIE, there should be address randomization (at >> least for data sections), which should be done in startup code. Is my >> understanding right? > > No, the kernel does the address randomization (the random base address it > loads the program at). The userspace side is just applying this base > address to the relative relocations in the rel/rela tables. > > Rich > >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.