RE: static PIE

[weimingz@codeaurora.org]

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@codeaurora.org]
> Sent: Wednesday, July 30, 2014 4:28 PM
> To: musl@lists.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@aerifal.cx]
> Sent: Wednesday, July 30, 2014 1:27 PM
> To: Weiming Zhao
> Cc: musl@lists.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[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
>
>