Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 1 Aug 2014 05:39:55 -0000
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!


> 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 []
> Sent: Wednesday, July 30, 2014 4:28 PM
> To:
> 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' []
> Sent: Wednesday, July 30, 2014 1:27 PM
> To: Weiming Zhao
> Cc:
> 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:
> 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[12].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.