PIE/PIC support on base

[Shawn Webb]

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?)?

Thanks,

Shawn