From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5688 Path: news.gmane.org!not-for-mail From: weimingz@codeaurora.org Newsgroups: gmane.linux.lib.musl.general Subject: RE: static PIE Date: Fri, 1 Aug 2014 05:39:55 -0000 Message-ID: <530b112f6d0faf956a58f858e533af2d.squirrel@www.codeaurora.org> References: <000001cfac2b$2030bd30$60923790$@codeaurora.org> <20140730202710.GN1674@brightrain.aerifal.cx> <003101cfac4d$d6820c20$83862460$@codeaurora.org> <003501cfac55$8242fea0$86c8fbe0$@codeaurora.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1406871615 4079 80.91.229.3 (1 Aug 2014 05:40:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Aug 2014 05:40:15 +0000 (UTC) Cc: musl@lists.openwall.com To: dalias@libc.org Original-X-From: musl-return-5693-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 01 07:40:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XD5ZZ-0007Xq-FH for gllmg-musl@plane.gmane.org; Fri, 01 Aug 2014 07:40:09 +0200 Original-Received: (qmail 25644 invoked by uid 550); 1 Aug 2014 05:40:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25636 invoked from network); 1 Aug 2014 05:40:08 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-caf-smtp.dmz.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00 autolearn=ham version=3.3.1 In-Reply-To: <003501cfac55$8242fea0$86c8fbe0$@codeaurora.org> User-Agent: SquirrelMail/1.4.22-4.el6 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Xref: news.gmane.org gmane.linux.lib.musl.general:5688 Archived-At: 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 > >