PIE/PIC support on base

Wed Nov 5 11:49:01 UTC 2014

On Wed, Nov 05, 2014 at 11:26:14AM +0200, Konstantin Belousov wrote:
> On Wed, Nov 05, 2014 at 10:02:15AM +0100, Baptiste Daroussin wrote:
> > On Fri, Oct 17, 2014 at 08:05:57AM -0600, Warner Losh wrote:
> > > [[cc trimmed ]]
> > > 
> > > On Oct 17, 2014, at 7:46 AM, Shawn Webb <lattera at gmail.com> wrote:
> > > 
> > > > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh <imp at bsdimp.com> wrote:
> > > > 
> > > > On Oct 17, 2014, at 2:05 AM, Shawn Webb <lattera at gmail.com> wrote:
> > > > 
> > > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen <jlh at freebsd.org> wrote:
> > > > >
> > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb <lattera at gmail.com> wrote:
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen <jlh at freebsd.org> wrote:
> > > > >>>>
> > > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier
> > > > >>>> <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> (which include <bsd.prog.mk>...) otherwise
> > > > >>>>> other
> > > > >>>>> binaries include <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.
> > > > >>>
> > > > >>> 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.
> > > > >>
> > > > >> OK.  As long as i386 is still an important architecture, it can make
> > > > >> sense to enable this on a per-binary basis if we don't want to have a
> > > > >> discrepancy between archs. Also I buy your argument on /bin/ls but I
> > > > >> was challenging to enable for the whole system because I wonder if
> > > > >> there aren't some unexpected attack surfaces, besides the obvious ones
> > > > >> (servers).
> > > > >>
> > > > >> Do you know what took so much time to OpenBSD?
> > > > >
> > > > >
> > > > > In a private conversation with Theo, I realized that my recollection of the
> > > > > time it took OpenBSD to compile all of base as PIEs was wrong. Quoting him:
> > > > >
> > > > > "It took 5 people approximately 3 months to debug it, activate it, and
> > > > > start shipping it the next release.  That was on amd64, for all
> > > > > dynamically linked binaries, except one (a gcc bug took some time to
> > > > > find).  The next architectures followed about 1 or 2 per 6-month
> > > > > release."
> > > > >
> > > > > Given that only one person has worked on this in the past (me) and now the
> > > > > task has been delegated to another (David Carlier), I think we're doing
> > > > > okay on our end. There's a lot of moving parts, and neither of us fully
> > > > > understand all of them completely. We're working on it in HardenedBSD, in
> > > > > the hardened/current/pie branch.
> > > > >
> > > > > I'm thinking we might try for a WITH_PIE knob (and *not* use USE_PIE) and
> > > > > have certain high-profile applications opt-in to PIE until we work out all
> > > > > the details for everything en masse. Baptiste did bring up a good point
> > > > > with INTERNALLIB and I'm unsure of how we should handle that.
> > > > 
> > > > WITH_PIE or WITHOUT_PIE controls, on a global basis, via the MK_PIE
> > > > variable, whether or not the user wants to turn on this feature for those
> > > > program that can do PIE. Designating which programs do, or don???t,
> > > > use PIE simply must be done with a different variable. I posted a bit of a
> > > > rant about the current state of things that suggested a couple of
> > > > alternatives as well as giving some history as to why some options
> > > > aren???t to be used and the history behind some of my reactions. :)
> > > > 
> > > > For this reason, I think WITH_PIE, as I understand your proposal,
> > > > likely isn???t a good fit with other WITH_xxx variables used in the src
> > > > tree today.
> > > > 
> > > > Gotcha. To be honest, I found your email a tad bit confusing. Are you suggesting we create an ENABLE_feature framework? Or are you suggesting we have a USE_PIE flag? Or are you suggesting something different entirely (and if you are, what?)?
> > > 
> > > I???m saying we don???t have a good framework at the moment to do this. We
> > > have several bad ones that all have their pitfalls. This is one reason I had
> > > the fast reaction to NO_PIE, then a minute later said ???go ahead and use
> > > it and I???ll fix it.??? I???m still cool with that position, btw.
> > > 
> > > As for a name, that can be debated a  lot, but I???d like to see something
> > > new, easy to use and unambiguous. If you are looking for a suggestion
> > > for that name, let???s go with WANTS_PIE. Only Makefiles can set it.
> > > 
> > > WANTS_PIE undefined means do the default behavior as defined by the
> > > current MK_PIE setting and perhaps system policy. ???Go with this flow."
> > > 
> > > WANTS_PIE=yes means that if MK_PIE is ???yes???, then do PIE things for
> > > this thing we???re building. If MK_PIE is ???no???, though PIE is disabled for
> > > everything.
> > > 
> > > WANTS_PIE=no means that if MK_PIE is ???yes???, then disable doing PIE
> > > things for this component. If MK_PIE is no, it is also disabled.
> > > 
> > > This could also be extended to NEEDS_foo, which says ???I need foo to
> > > build, and if MK_foo is set to no, don???t build me.??? I don???t think anything
> > > that you are doing falls into this category though.
> > > 
> > > WANTS/NEEDS also avoids the historical use of USE in the ports tree
> > > possibly creating confusion. 
> > > 
> > > If you go with WANTS_PIE, then you wouldn???t need bad.*.pie.mk.
> > > 
> > > Comments?
> > > 
> > > Warner
> > 
> > On amd64 WANTS_PIE will be useless as we can easily activate PIE on every places
> > For i386 we would propably prefer cherry picking the what we want to see built
> > with PIE. Don't know for other arches.
> > 
> > So here is what I do propose:
> > if MK_PIE=no: no PIE at all
> > if MK_PIE=yes:
> > - on amd64/(platforms without performance penalty): build everything with PIE
> >   from libs to prog
> See below.
> 
> > - on i386/(platforms with performance penalty): build with PIE if WANTS_PIE
> >   is defined.
> > 
> > So the difference with the previous approach are:
> > - No way to opt out PIE for a single binary either totally disable or enable (I
> >   have encountered no binary so far in the base system which fails with PIE
> >   enabled - again only tested on amd64)
> > - Activate PIE for both binaries and libraries (no reason not to include
> >   libraries)
> What does it mean 'PIE for library' ? There is simply no such thing.

Sorry I badly explained, I was meaning PIC for libs PIE for binaries.
> 
> Also, I strongly oppose compiling everything with PIC, even on amd64.
> I described somewhere else that using PIC code changes symbol lookup
> rules for binaries.  So despite not having performance impact, the
> thing does impact runtime behaviour in subtle ways.  The most affected
> programs are those which support dynamic modules.
> 
> Also, what is the state of static binaries + PIE ? Do our binutils
> support this at all ? The csu is definitely not ready for 'everything
> PIE'.

Only dynamic binaries will receive PIE support (and in case of using an
INTERNALLIB will link to the libbla_pic.a) static ones will remain non PIE.

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141105/fca9c632/attachment.sig>