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