Date: Wed, 5 Nov 2014 11:26:14 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: PaX Team <pageexec@freemail.hu>, Shawn Webb <lattera@gmail.com>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: PIE/PIC support on base Message-ID: <20141105092614.GB53947@kib.kiev.ua> In-Reply-To: <20141105090215.GF10388@ivaldir.etoilebsd.net> References: <CAGSa5y3s9r0DRyinfqV=PJc_BT=Em-SLfwhD25nP0=6ki9pHWw@mail.gmail.com> <CAMe1fxaBEc5T77xjpRsMi_kkc5LXwPGooLWTO9C1FJcLSPnO8w@mail.gmail.com> <CAGSa5y2=bKpaeLO_S5W%2B1YGq02WMgCZn_5bbEMw%2Bx3j-MYDOoA@mail.gmail.com> <CADt0fhzg5G1cLEBNfHXSEi9iP7mCP=8sSwpXbFobig=pm=QsFQ@mail.gmail.com> <CAGSa5y1LBxkUNSgKkw=F9_uykXDeBV7_WL0a7Wt%2B%2BGgMTSULEQ@mail.gmail.com> <CADt0fhweiymn2D09%2Be7f44AreWe%2B8cmAtDVeec0NfmuWuOOhbg@mail.gmail.com> <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> <CADt0fhyCBa3PTnZ3dpc-hpysyC9V0MXR16s-e10V0ioAfaWHuw@mail.gmail.com> <C7C48B02-E65C-4F90-A503-1FDDCB590B7D@bsdimp.com> <20141105090215.GF10388@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> wrote: > > > > > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh <imp@bsdimp.com> wrote: > > > > > > On Oct 17, 2014, at 2:05 AM, Shawn Webb <lattera@gmail.com> wrote: > > > > > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen <jlh@freebsd.org> wrote: > > > > > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb <lattera@gmail.com> wrote: > > > >>> > > > >>> > > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen <jlh@freebsd.org> wrote: > > > >>>> > > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > > >>>> <david.carlier@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. 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'. > > If we are ok with this I will publish a patch with does it in the next couple of > week. > > We can start by only supporting amd64 as fully PIE first then slowly add other > platforms. > > What do you think? > > regards, > Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141105092614.GB53947>