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 13:05, H.J. Lu wrote:
> On Thu, Mar 19, 2015 at 12:15 PM, 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.  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
> 
> Does PIE GCC work with PCH?  It didn't work for me last time when
> I tried.

PCH does fail miserably still, although it doesn't require PIE.  we've just 
accepted that it'll never be resolved and the extra build-time overhead is 
worth the run-time security.

https://gcc.gnu.org/PR52194
-mike

Attachment: signature.asc
Description: Digital signature