From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 15:59:16 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7B9B7D9 for ; Fri, 17 Oct 2014 15:59:16 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id A4502A30 for ; Fri, 17 Oct 2014 15:59:16 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2D7AA5A9F25; Fri, 17 Oct 2014 15:59:10 +0000 (UTC) Date: Fri, 17 Oct 2014 15:59:10 +0000 From: Brooks Davis To: Warner Losh Subject: Re: PIE/PIC support on base Message-ID: <20141017155909.GB22778@spindle.one-eyed-alien.net> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: PaX Team , FreeBSD Arch , Shawn Webb X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:59:17 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 08:05:57AM -0600, Warner Losh wrote: > [[cc trimmed ]] >=20 > On Oct 17, 2014, at 7:46 AM, Shawn Webb wrote: >=20 > > On Fri, Oct 17, 2014 at 9:41 AM, Warner Losh wrote: > >=20 > > On Oct 17, 2014, at 2:05 AM, Shawn Webb wrote: > >=20 > > > On Fri, Oct 17, 2014 at 3:53 AM, Jeremie Le Hen wro= te: > > > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb wro= te: > > >>> > > >>> > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen w= rote: > > >>>> > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > >>>> 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 on= ly if > > >>>>> you > > >>>>> include (which include ...) otherw= ise > > >>>>> other > > >>>>> binaries include 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 Br= uno. > > >>> > > >>> On i386, there is a performance cost due to not having an extra reg= ister > > >>> available for the relocation work that has to happen. PIE doesn't c= arry > > >> 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, th= ere > > >> is no > > >>> further performance penalty due to amd64 having an extra register t= o use > > >> for > > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carries o= n 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 personal= ly > > >> 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 sta= rt. > > >>> Providing a framework for application developers to opt their appli= cation > > >>> 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 on= es > > >> (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. Quotin= g 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 no= w the > > > task has been delegated to another (David Carlier), I think we're doi= ng > > > okay on our end. There's a lot of moving parts, and neither of us ful= ly > > > 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 ou= t all > > > the details for everything en masse. Baptiste did bring up a good poi= nt > > > with INTERNALLIB and I'm unsure of how we should handle that. > >=20 > > 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 tho= se > > 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 o= f 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. :) > >=20 > > 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. > >=20 > > Gotcha. To be honest, I found your email a tad bit confusing. Are you s= uggesting we create an ENABLE_feature framework? Or are you suggesting we h= ave a USE_PIE flag? Or are you suggesting something different entirely (and= if you are, what?)? >=20 > 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. >=20 > 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. >=20 > WANTS_PIE undefined means do the default behavior as defined by the > current MK_PIE setting and perhaps system policy. ?Go with this flow." >=20 > WANTS_PIE=3Dyes 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. >=20 > WANTS_PIE=3Dno means that if MK_PIE is ?yes?, then disable doing PIE > things for this component. If MK_PIE is no, it is also disabled. >=20 > 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. >=20 > WANTS/NEEDS also avoids the historical use of USE in the ports tree > possibly creating confusion.=20 >=20 > If you go with WANTS_PIE, then you wouldn?t need bad.*.pie.mk. >=20 > Comments? I think WANTS/NEEDS would address the cases where we've added USE_ variables in our (SRI/Cambridge) external tree. I agree it's a good idea to keep the names orthogonal with ports. -- Brooks --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRBPM0ACgkQXY6L6fI4GtRiRQCfXsxjo3XtzxgyR5sDYN6bp3WB rKgAoIcBzJ7zQB95gwt6xQd99Lm56C09 =gF2V -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5--