From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5680 Path: news.gmane.org!not-for-mail From: "Weiming Zhao" Newsgroups: gmane.linux.lib.musl.general Subject: static PIE Date: Wed, 30 Jul 2014 12:19:03 -0700 Message-ID: <000001cfac2b$2030bd30$60923790$@codeaurora.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CFABF0.73D3B9F0" X-Trace: ger.gmane.org 1406747997 30075 80.91.229.3 (30 Jul 2014 19:19:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 19:19:57 +0000 (UTC) To: "'Rich Felker'" , Original-X-From: musl-return-5685-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 30 21:19:52 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 1XCZPC-0001pt-2S for gllmg-musl@plane.gmane.org; Wed, 30 Jul 2014 21:19:18 +0200 Original-Received: (qmail 22408 invoked by uid 550); 30 Jul 2014 19:19:17 -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 22397 invoked from network); 30 Jul 2014 19:19:16 -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.2 required=2.0 tests=ALL_TRUSTED,BAYES_40, HTML_MESSAGE,TVD_RCVD_SINGLE autolearn=no version=3.3.1 X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+sKx9p6+GuIv+DQnqpCJ+qpxkfOQ== Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Xref: news.gmane.org gmane.linux.lib.musl.general:5680 Archived-At: This is a multipart message in MIME format. ------=_NextPart_000_0001_01CFABF0.73D3B9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Rich, I just find a very interesting article written by you: http://www.openwall.com/lists/musl/2012/05/24/1 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. But with "-static", those reloc entries has already been fixed by ld. Without that, my code can still run but at fixed address space. 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? Thanks, weiming ------=_NextPart_000_0001_01CFABF0.73D3B9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rich,

 

I just find = a very interesting article written by you:

http://www.openw= all.com/lists/musl/2012/05/24/1

 

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.

 

But with “-static”, those reloc entries = has already been fixed by ld. Without that, my code can still run but at = fixed address space.

 

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?

 

Thanks,

weiming

------=_NextPart_000_0001_01CFABF0.73D3B9F0-- From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5681 Path: news.gmane.org!not-for-mail From: 'Rich Felker' Newsgroups: gmane.linux.lib.musl.general Subject: Re: static PIE Date: Wed, 30 Jul 2014 16:27:10 -0400 Message-ID: <20140730202710.GN1674@brightrain.aerifal.cx> References: <000001cfac2b$2030bd30$60923790$@codeaurora.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1406752052 18087 80.91.229.3 (30 Jul 2014 20:27:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 20:27:32 +0000 (UTC) Cc: musl@lists.openwall.com To: Weiming Zhao Original-X-From: musl-return-5686-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 30 22:27:27 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 1XCaT7-0000Gm-0R for gllmg-musl@plane.gmane.org; Wed, 30 Jul 2014 22:27:25 +0200 Original-Received: (qmail 3175 invoked by uid 550); 30 Jul 2014 20:27:24 -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 3164 invoked from network); 30 Jul 2014 20:27:24 -0000 Content-Disposition: inline In-Reply-To: <000001cfac2b$2030bd30$60923790$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5681 Archived-At: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5682 Path: news.gmane.org!not-for-mail From: "Weiming Zhao" Newsgroups: gmane.linux.lib.musl.general Subject: RE: static PIE Date: Wed, 30 Jul 2014 16:27:32 -0700 Message-ID: <003101cfac4d$d6820c20$83862460$@codeaurora.org> References: <000001cfac2b$2030bd30$60923790$@codeaurora.org> <20140730202710.GN1674@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406762872 15870 80.91.229.3 (30 Jul 2014 23:27:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Jul 2014 23:27:52 +0000 (UTC) To: Original-X-From: musl-return-5687-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 31 01:27:47 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 1XCdHf-0000Fw-1g for gllmg-musl@plane.gmane.org; Thu, 31 Jul 2014 01:27:47 +0200 Original-Received: (qmail 5250 invoked by uid 550); 30 Jul 2014 23:27:45 -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 5242 invoked from network); 30 Jul 2014 23:27:45 -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=-0.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, TVD_RCVD_SINGLE autolearn=no version=3.3.1 In-Reply-To: <20140730202710.GN1674@brightrain.aerifal.cx> X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ7QNOT9cfhMKbYmwOc89lb71ebjgJKTs/ymk/A3BA= Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Xref: news.gmane.org gmane.linux.lib.musl.general:5682 Archived-At: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5683 Path: news.gmane.org!not-for-mail From: "Weiming Zhao" Newsgroups: gmane.linux.lib.musl.general Subject: RE: static PIE Date: Wed, 30 Jul 2014 17:22:23 -0700 Message-ID: <003401cfac55$805670e0$810352a0$@codeaurora.org> References: <000001cfac2b$2030bd30$60923790$@codeaurora.org> <20140730202710.GN1674@brightrain.aerifal.cx> <003101cfac4d$d6820c20$83862460$@codeaurora.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1406766162 16982 80.91.229.3 (31 Jul 2014 00:22:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jul 2014 00:22:42 +0000 (UTC) To: Original-X-From: musl-return-5688-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 31 02:22:37 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 1XCe8j-0003Sa-A0 for gllmg-musl@plane.gmane.org; Thu, 31 Jul 2014 02:22:37 +0200 Original-Received: (qmail 5617 invoked by uid 550); 31 Jul 2014 00:22:36 -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 5606 invoked from network); 31 Jul 2014 00:22:36 -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=-0.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, TVD_RCVD_SINGLE autolearn=no version=3.3.1 In-Reply-To: <003101cfac4d$d6820c20$83862460$@codeaurora.org> X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ7QNOT9cfhMKbYmwOc89lb71ebjgJKTs/yAkINZYSaPcTb0A== Content-Language: en-us X-Virus-Scanned: ClamAV using ClamSMTP Xref: news.gmane.org gmane.linux.lib.musl.general:5683 Archived-At: 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 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 > >