From owner-freebsd-arch@FreeBSD.ORG Wed Nov 5 11:49:01 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 1261BED8 for ; Wed, 5 Nov 2014 11:49:01 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91AD0BD4 for ; Wed, 5 Nov 2014 11:49:00 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so694600wgg.33 for ; Wed, 05 Nov 2014 03:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YXj7gqNRDV7AdryLVk3F/3jHjfJ5NgO4k5ERoYsTtW4=; b=vnVKKeW/gXm4cmIa8oTcZSXt/JSfnTUBWOvWDflvKFYoXCizyjKXOgCz1Hq/zMHEzU OQENAEcGUiobd62LMNBfAfwlDvFOeFjKKV4ujUg5ap1V26N1hWtDDK0PwPsKlzB7l0dM Jzpgw+vO4JqWUuc+QCqODtHBt/NE3TX58LjGR8rdLtsuxDLcIPFNNBbXwQ3dEyTQ6khQ CmLHiFYDjjrwyr9w0hXmrdyXHBm1U9gv9k+TuoYLLlrIVMAOY6QJQmkb/RnxbMXkX0MY TRRsor+VZnd4KLud+Mv4ZZ19rmDCtFeinSkYoyUgEypVhTKZAQDe7W3zCk3IOcETfzfU zTKg== X-Received: by 10.180.107.230 with SMTP id hf6mr25556493wib.31.1415188138769; Wed, 05 Nov 2014 03:48:58 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id dw9sm4326879wib.0.2014.11.05.03.48.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Nov 2014 03:48:57 -0800 (PST) Sender: Baptiste Daroussin Date: Wed, 5 Nov 2014 12:48:55 +0100 From: Baptiste Daroussin To: Konstantin Belousov Subject: Re: PIE/PIC support on base Message-ID: <20141105114855.GH10388@ivaldir.etoilebsd.net> References: <315B4DC5-0E04-4F6B-BBB0-477D049025BF@bsdimp.com> <20141105090215.GF10388@ivaldir.etoilebsd.net> <20141105092614.GB53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wj9ZLJVQDRFjGSdK" Content-Disposition: inline In-Reply-To: <20141105092614.GB53947@kib.kiev.ua> 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: Wed, 05 Nov 2014 11:49:01 -0000 --wj9ZLJVQDRFjGSdK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 ]] > > >=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 = wrote: > > > > > > > > > >> On Fri, Oct 17, 2014 at 12:15 AM, Shawn Webb = wrote: > > > > >>> > > > > >>> > > > > >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen wrote: > > > > >>>> > > > > >>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier > > > > >>>> wrote: > > > > >>>>> > > > > >>>>> I chose the "atomic" approach, at the moment very few binarie= s are > > > > >>>>> concerned at the moment. So I applied INCLUDE_PIC_ARCHIVE in = the > > > > >> needed > > > > >>>>> libraries plus created WITH_PIE which add fPIE/fpie -pie flag= s only if > > > > >>>>> you > > > > >>>>> include (which include ...) ot= herwise > > > > >>>>> other > > > > >>>>> binaries include as usual hence does not apply.= Look > > > > >>>>> reasonable approach ? > > > > >>>> > > > > >>>> I think I understand what you mean. But I think PIE is common= place > > > > >>>> nowadays and I don't understand what you win by not enabling i= t for > > > > >>>> the whole system. Is it a performance concern? Is it to pres= erve > > > > >>>> conservative minds from to much change? :) > > > > >>> > > > > >>> > > > > >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sea= n 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 s= ome on > > > > >> first > > > > >>> resolution of functions (due to the extra relocation step the R= TLD has to > > > > >>> worry about). On amd64, after symbol resolution has taken place= , there > > > > >> is no > > > > >>> further performance penalty due to amd64 having an extra regist= er to use > > > > >> for > > > > >>> PIE/PIC. I'm unsure what, if any, performance penalty PIE carri= es 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 pers= onally > > > > >> would > > > > >>> like to see all of base's applications compiled as PIEs, but th= at's a > > > > >> long > > > > >>> ways off. It took OpenBSD several years to accomplish that. Hav= ing > > > > >> certain > > > > >>> high-visibility applications (like sshd, inetd, etc) is a great= start. > > > > >>> Providing a framework for application developers to opt their a= pplication > > > > >>> 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 h= ave a > > > > >> discrepancy between archs. Also I buy your argument on /bin/ls b= ut I > > > > >> was challenging to enable for the whole system because I wonder = if > > > > >> there aren't some unexpected attack surfaces, besides the obviou= s ones > > > > >> (servers). > > > > >> > > > > >> Do you know what took so much time to OpenBSD? > > > > > > > > > > > > > > > In a private conversation with Theo, I realized that my recollect= ion of the > > > > > time it took OpenBSD to compile all of base as PIEs was wrong. Qu= oting 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) an= d 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 Hardene= dBSD, 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 wor= k 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. > > > >=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= 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 b= it 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. :) > > > >=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 y= ou 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?)? > > >=20 > > > I???m saying we don???t have a good framework at the moment to do thi= s. We > > > have several bad ones that all have their pitfalls. This is one reaso= n 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 some= thing > > > 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 flo= w." > > >=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 dis= abled 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 thi= nk 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? > > >=20 > > > Warner > >=20 > > On amd64 WANTS_PIE will be useless as we can easily activate PIE on eve= ry places > > For i386 we would propably prefer cherry picking the what we want to se= e built > > with PIE. Don't know for other arches. > >=20 > > So here is what I do propose: > > if MK_PIE=3Dno: no PIE at all > > if MK_PIE=3Dyes: > > - on amd64/(platforms without performance penalty): build everything wi= th PIE > > from libs to prog > See below. >=20 > > - on i386/(platforms with performance penalty): build with PIE if WANTS= _PIE > > is defined. > >=20 > > So the difference with the previous approach are: > > - No way to opt out PIE for a single binary either totally disable or e= nable (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. >=20 > 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. >=20 > 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 --wj9ZLJVQDRFjGSdK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRaDqcACgkQ8kTtMUmk6ExcHgCfSOml3H4uNy+jydng/YK8vPvb fJkAn0JRULihj9CuCOIcFwdkSCiw0wwt =nVSZ -----END PGP SIGNATURE----- --wj9ZLJVQDRFjGSdK--