Re: Is it a GNU Tools failure that PIE use ET_DYN and can't be distinguished from libraries?

[Mike Frysinger <vapier at gentoo dot org>]

On 19 Mar 2015 00:27, Rich Felker wrote:
> On Wed, Mar 18, 2015 at 09:37:46PM -0400, Carlos O'Donell wrote:
> > On 03/18/2015 04:51 PM, Roland McGrath wrote:
> > >> Is it a failing of the tooling that we didn't provide a way for
> > >> tools to determine PIE vs. DSO?
> > > 
> > > It might be if we hadn't.  But we defined a PIE as an ET_DYN with a
> > > DT_DEBUG.  (We didn't account for a case that would be useful and the
> > > linker doesn't currently fully support: a static PIE, which is an ET_DYN
> > > that has no PT_INTERP and might not have a PT_DYNAMIC either.)
> > 
> > Interesting, ET_DYN + DT_DEBUG, I did not see that coming.
> > 
> > At best I'd have defined it as ET_DYN + PT_INTERP, and I would have
> > been happy to call libc.so.6 the first PIE.
> 
> That excludes static pie, something I've successfully experimented
> with using musl and which the OpenBSD folks seem to be doing
> independently. AFAIK there's no upstream toolchain support for it, but
> gcc can be tricked into doing something that works with -shared
> (instead of -pie), -Wl,-Bstatic, and explicitly including a version of
> crt1.o (OpenBSD calls this rcrt0.o, I think; my experimental version
> was called Zcrt1.o) that processes RELATIVE relocs.

from what i can tell, missing static PIE support is a matter of no one putting 
in the work in all the various places to make it a reality vs any one actively 
lobbying against it.  i'd like to see it happen ... mostly because when you have 
a system that is fully PIE down to the compiler (like Gentoo/Hardened), not 
being able to build static ELFs is annoying.  all the static archives contain 
PIE objects.
-mike

Attachment: signature.asc
Description: Digital signature