Fwd: PIE/PIC support on base

David Carlier david.carlier at hardenedbsd.org
Fri Oct 17 04:56:04 UTC 2014


---------- Forwarded message ----------
From: David Carlier <david.carlier at hardenedbsd.org>
Date: Fri, Oct 17, 2014 at 5:52 AM
Subject: Re: PIE/PIC support on base
To: Jeremie Le Hen <jlh at freebsd.org>, Baptiste Daroussin <bapt at freebsd.org>,
Shawn Webb <shawn.webb at hardenedbsd.org>


Except Baptiste, what do you all think about USE_PIE versus WITH_PIE ?

On Thu, Oct 16, 2014 at 11:37 PM, Bryan Drewery <bdrewery at freebsd.org>
wrote:

> On 10/16/2014 5:15 PM, Shawn Webb wrote:
> >
> >
> > On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen <jlh at freebsd.org
> > <mailto:jlh at freebsd.org>> wrote:
> >
> >     On Thu, Oct 16, 2014 at 8:21 PM, David Carlier
> >     <david.carlier at hardenedbsd.org
> >     <mailto:david.carlier at hardenedbsd.org>> wrote:
> >     >
> >     > I chose the "atomic" approach, at the moment very few binaries are
> >     > concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in the
> needed
> >     > libraries plus created WITH_PIE which add fPIE/fpie -pie flags
> only if you
> >     > include <bsd.prog.pie.mk <http://bsd.prog.pie.mk>> (which include
> >     <bsd.prog.mk <http://bsd.prog.mk>>...) otherwise other
> >     > binaries include <bsd.prog.mk <http://bsd.prog.mk>> as usual
> hence does not apply. Look
> >     > reasonable approach ?
> >
> >     I think I understand what you mean.  But I think PIE is commonplace
> >     nowadays and I don't understand what you win by not enabling it for
> >     the whole system.  Is it a performance concern?  Is it to preserve
> >     conservative minds from to much change? :)
> >
> >
> > Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean Bruno.
> >
> > On i386, there is a performance cost due to not having an extra register
> > available for the relocation work that has to happen. PIE doesn't carry
> > much of a performance penalty on amd64, though it still does carry some
> > on first resolution of functions (due to the extra relocation step the
> > RTLD has to worry about). On amd64, after symbol resolution has taken
> > place, there is no further performance penalty due to amd64 having an
> > extra register to use for PIE/PIC. I'm unsure what, if any, performance
> > penalty PIE carries on ARM, AArch64, and sparc64.
> >
>
> I think if the performance impact can be well understood on all
> architectures, and that it is not more than a few % points, other people
> may be more willing to enable it on all. I can't speak for them, but if
> the impact is not significant then it is safer and simpler to enable
> everywhere and I would think that argument would win over anything else.
> What do I know though? That approach failed already.
>
> > Certain folk would prefer to see PIE enabled only in certain
> > applications. /bin/ls can't really make much use of PIE. But sshd can. I
> > personally would like to see all of base's applications compiled as
> > PIEs, but that's a long ways off. It took OpenBSD several years to
> > accomplish that. Having certain high-visibility applications (like sshd,
> > inetd, etc) is a great start. Providing a framework for application
> > developers to opt their application into PIE is another great start.
> >
> > Those are my two cents.
> >
> > Thanks,
> >
> > Shawn
>
>
> --
> Regards,
> Bryan Drewery
>
>


More information about the freebsd-arch mailing list