[<prev] [next>] [day] [month] [year] [list]
Message-ID: <530b112f6d0faf956a58f858e533af2d.squirrel@www.codeaurora.org>
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[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.
