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

[Rich Felker <dalias at libc dot org>]

On Thu, Mar 19, 2015 at 03:15:50PM -0400, Mike Frysinger wrote:
> 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.

Yes, I agree and I hope my message didn't imply that anyone is
lobbying against it. My intent was just to express that requiring
PT_INTERP as part of the definition of PIE (vs shared lib) would be a
bad idea since it would preclude static PIE.

> 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.

Yes. At present I don't think you're unable to build static binaries;
right now, -static should override -pie, but it results in a fixed
load address being determined at link-time rather than linking
alternate startup code to support relative relocation at load time.

BTW in the above info on static PIE and how to "make it work" right
now, I left out -Wl,-Bsymbolic. Without that, non-relative relocations
will be left in the output which would require much heavier startup
code capable of performing symbol lookups. Presumably when static PIE
is part of the default toolchain, this will be handled automatically.

Note that there's also another optional variant of static PIE where
PT_INTERP is still used and no special startup code is needed. This
can be achieved right now by -Wl,-Bstatic and -pie. This variant is
not useful to me with musl because part of my goal is for users to be
able to deploy static binaries to systems without musl's dynamic
linker present in /lib, and likewise I think it's a less-attractive
option for glibc because the resulting binaries can't be deployed to
non-glibc-based systems, but it is a workable option right now.

Rich