From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7849 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.gnu.binutils Subject: Static PIE support in GCC Date: Mon, 1 Jun 2015 17:26:15 -0400 Message-ID: <20150601212615.GA23542@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 X-Trace: ger.gmane.org 1433194005 29295 80.91.229.3 (1 Jun 2015 21:26:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Jun 2015 21:26:45 +0000 (UTC) Cc: musl@lists.openwall.com, binutils@sourceware.org To: gcc@gcc.gnu.org Original-X-From: musl-return-7862-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 01 23:26:44 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YzXEK-0002Ds-2L for gllmg-musl@m.gmane.org; Mon, 01 Jun 2015 23:26:44 +0200 Original-Received: (qmail 6061 invoked by uid 550); 1 Jun 2015 21:26:42 -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 5965 invoked from network); 1 Jun 2015 21:26:31 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7849 gmane.comp.gcc.devel:140038 gmane.comp.gnu.binutils:69965 Archived-At: A feature I've been interested in getting upstream in GCC for a while now is support for producing static-linked PIE executables for Linux. In the model I'm working with, static PIE executables are ET_DYN format with no PT_INTERP, and are intended to contain only relative type relocations (no symbol references). A custom crt1 start file named rcrt1.o is responsible for processing these relative relocations before passing execution to the libc entry point code. I have as part of musl libc an implementation of rcrt1.o (for all targets musl presently supports) that's working for this model. The way it works is completely analogous to what OpenBSD has done in their fork of GCC (see http://www.openbsd.org/papers/asiabsdcon2015-pie-slides.pdf), but aside from adopting the 'r' prefix for crt that they used, which I did for some level of consistency, my work on static PIE has been completely independent of the development of this feature in OpenBSD. While OpenBSD's motivations for static PIE seem to be purely security focused, I'm also interested in static PIE as a form of executable that can be used on NOMMU targets. My motivation for doing the relocations in the start file, rather than with an external program interpreter, is both to reduce runtime cost on very small systems, and to make deployment easier. For musl users, one of the main benefits of static linking is that the resulting binary can be run on systems without any additional runtime files installed. Unfortunately, producing static PIE binaries with GCC is not as simple as passing -static -pie when linking. The linker arguments I've been using to test this so far have been: -shared -Wl,-Bstatic -Wl,-Bsymbolic and adding the rcrt1.o to the beginning of the inputs. This looks like something of a hack, and on the GCC command line I would say it is, at least for -shared which is being used both to suppress the default crt1 file and to produce ET_DYN output without PT_INTERP. On the other hand,-Bstatic is just being used to suppress use of .so files to satisfy -l dependencies, and -Bsymbolic to produce relative relocations in the output instead of symbol references. Thankfully this gets a lot less ugly if you put it in the specs. Just replacing: #define LINK_PIE_SPEC "%{pie:-pie} " with: #define LINK_PIE_SPEC "%{pie:%{static:-shared -Bsymbolic;:-pie}} " causes -static -pie to invoke the linker in a manner which matches the desired static PIE model. Aside from this, a per-target addition to STARTFILE_SPEC is needed to make GCC choose rcrt1.o instead of Scrt1.o when -static is used with -pie, and to change the logic for crtbegin so that -pie's choice of crtbeginS.o overrides -static's crtbeginT.o, and likewise for crtend. Before proposing anything in the way of patches I'd like some feedback on whether this approach is acceptable for upstreaming in GCC. The obvious alternative to the LINK_PIE_SPEC change is making ld accept -static -pie and do "the right thing" on its side, but the startfile changes needed on the GCC side are the same either way. Rich