From: "Weiming Zhao" <weimingz@codeaurora.org>
To: <musl@lists.openwall.com>
Subject: RE: static PIE
Date: Wed, 30 Jul 2014 17:22:23 -0700 [thread overview]
Message-ID: <003401cfac55$805670e0$810352a0$@codeaurora.org> (raw)
In-Reply-To: <003101cfac4d$d6820c20$83862460$@codeaurora.org>
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
next prev parent reply other threads:[~2014-07-31 0:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 19:19 Weiming Zhao
2014-07-30 20:27 ` 'Rich Felker'
2014-07-30 23:27 ` Weiming Zhao
2014-07-31 0:22 ` Weiming Zhao [this message]
[not found] ` <003501cfac55$8242fea0$86c8fbe0$@codeaurora.org>
2014-08-01 5:39 ` weimingz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003401cfac55$805670e0$810352a0$@codeaurora.org' \
--to=weimingz@codeaurora.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).