From owner-freebsd-arch@FreeBSD.ORG Fri Oct 17 05:23:15 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 24DEEB6F for ; Fri, 17 Oct 2014 05:23:15 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 D987C341 for ; Fri, 17 Oct 2014 05:23:14 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id h15so963178igd.10 for ; Thu, 16 Oct 2014 22:23:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=kYFgMIPgZSCGNr7kEMromGTYbd7+VpIQwxUHA+rZnzk=; b=P1VKsKhm+fsgduqjufdu+96rlF4tYZD93YOQKGk53wCynrr7MnRzey/3Top2iNFZe2 wV8f5ajVJ5Gx02uc8irKUZwPHMKCaSnes5aRBSTgcS/uHgRPy5IAVc/NrM/P/df6k9Kf qr/sqQjkYEaYYLdhPVNq3X5JefGY7U9zacUq6KJFVLwb3UCtFiAaviXFjlGl/oA9KXgS 3FWVx2zMchvcOaEYP3E8d6Jga8nohpSD+iQSSjCNqPi6JNZv0sfB1FjT79Ke7BxrVBFS QO5pX9TKrXnkVTmoJakDrx52HFJHo8EnVSDlq18t3+xQ7itaSIGR5kFwTUvSoUEEULN3 FBdw== X-Gm-Message-State: ALoCoQkSy3rNKxA37G1Yq6HO/0bqTqY60xghZoW/DhdQQRvdHSfrG/tAjtOgy1Dh6SDWIZsHdmva X-Received: by 10.42.151.66 with SMTP id d2mr3744icw.74.1413523387893; Thu, 16 Oct 2014 22:23:07 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o8sm458329igh.12.2014.10.16.22.23.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 22:23:07 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: PIE/PIC support on base From: Warner Losh In-Reply-To: Date: Thu, 16 Oct 2014 22:23:04 -0700 Message-Id: <35058403-E24F-4243-ABD1-CE82A1764977@bsdimp.com> References: <5440489F.3080602@FreeBSD.org> To: David Carlier X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org 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 05:23:15 -0000 --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So, WITH_PIE -> MK_PIE =3D=3D yes. This says =93for the things that support PIE, build them.=94 This would = be a user-accessable knob (not Makefile accessible) that would enable things. MK_PIE would = likely be tested in some *.mk files, and maybe in some Makefiles but likely not. = Makefiles are absolutely forbidden[*] from setting WITHOUT_foo or WITH_foo. And then there=92s =93USE_PIE" What does that mean? There=92s nothing else in the src tree that uses = that paradigm, except in the obscure backwater of bsd.doc.mk, which is used for just = share/doc documents. There it used control which tools in the pic / tbl / etc are = used. If it is defined, then the tool is placed in the chain. It is a Makefile only = setting that=92s not a user accessible part. This suggests that we could rescue it from this = obscure corner. It=92s also used in ports to enable a features, but in a different way = than we=92re describing here. It describes a dependency chain needed for the port, rather than = turning on or off a latent feature. What do you propose it to mean? What do you propose USE_foo to mean = generally? Are there other options in the tree that would make sense to transition = to USE_xxx. Does it just have to be defined, or is there a value associated with it? = USE_xxx=3D{yes,no} would mean what exactly in a Makefile? The whole reason we went to = MK_xxx in the past was because it was too difficult to change the defaults for = some option. Used carefully, USE_xxx might not fall into that trap, but I=92m skeptical. Today, things like this are done with NO_xxxx in a few places. We have a = small number of these in the tree. NO_PIC, NO_INFO_COMPRESS, NO_EXTRADEPEND, NO_FSCHG, NO_LINT, NO_SUBDIR, NO_MLINKS, NO_OBJ, and the infamous NO_SHARED. They mean a variety of different things. Some are ancient = vestiges of the system of user configuration that predates MK_foo. Some are set = in Makefiles to control things. Some are a bit of both. And there are no words to = described NO_SHARED=3Dno, which is what lead, in part, to the NOxxx jihad of the = late 1990s. I=92d rather like to avoid any new NO options. Oh, and I=92m glad YES_HESIOD = is now in the dustbin of history. If I were designing things, I=92d suggest we invent something new. = ENABLE_xxx and DISABLE_xxx which would change the default behavior around the xxx = feature. Warner [*] Except the top level Makefile and some in release/=85 But these uses = are transitioning to MK_xxx=3D{yes,no} instead. On Oct 16, 2014, at 9:55 PM, David Carlier = wrote: > ---------- Forwarded message ---------- > From: David Carlier > Date: Fri, Oct 17, 2014 at 5:52 AM > Subject: Re: PIE/PIC support on base > To: Jeremie Le Hen , Baptiste Daroussin = , > Shawn Webb >=20 >=20 > Except Baptiste, what do you all think about USE_PIE versus WITH_PIE ? >=20 > On Thu, Oct 16, 2014 at 11:37 PM, Bryan Drewery > wrote: >=20 >> On 10/16/2014 5:15 PM, Shawn Webb wrote: >>>=20 >>>=20 >>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen >> > wrote: >>>=20 >>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >>> >> > wrote: >>>>=20 >>>> 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 > (which include >>> >...) otherwise other >>>> binaries include > as usual >> hence does not apply. Look >>>> reasonable approach ? >>>=20 >>> 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? :) >>>=20 >>>=20 >>> Looping in Kostik, Bryan Drewery, the PaX team, Hunger, and Sean = Bruno. >>>=20 >>> 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. >>>=20 >>=20 >> I think if the performance impact can be well understood on all >> architectures, and that it is not more than a few % points, other = people >> may be more willing to enable it on all. I can't speak for them, but = if >> the impact is not significant then it is safer and simpler to enable >> everywhere and I would think that argument would win over anything = else. >> What do I know though? That approach failed already. >>=20 >>> 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. >>>=20 >>> Those are my two cents. >>>=20 >>> Thanks, >>>=20 >>> Shawn >>=20 >>=20 >> -- >> Regards, >> Bryan Drewery >>=20 >>=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQKe5AAoJEGwc0Sh9sBEAM2sQALzy1KX+GNAJhiAElptO9i+h 65ymN3MbBUd4dksVqPYU6w6kVe+nFzcqMCg+zWlHdjdy+Gf+Vo9rSELPOkw5T38S W+UHtd4NSgNxyLW3anMpyWo6tJkkGlz5ReOn9JKPoSwfj0tSQwU8fGhpFDd2e1YJ uMNN+6aMvbVQYaw/wXTCS4SazG0GTI7Ts9LP3mKolODHW8ZU30pElA7UP7sGN/qD q5AfvcVrXR7aJGL/RUGJHaDIQ4KiYRRcDNsOlOVYoKNO1Q4flJuNrk5i68u2DVll ZhANqkZQOWgsiPGoktuVIUDOGPzcK39raDGlQDSSShNQ9xLcJjoP1DyxyvlfsfwA ozeCNajvxvrGtxlAIXLuQ7z0xCnmh7I2WFTgu3bCajYSLapeS1sxxTzrTmqJY+Sr T0OXtePBJvjAFOEveEmiZ7s8O5+XMP1lnobqLuuVxcEcEYyCUVc4CCcg6x/8bBBN REVyrBqNUoXCavPBkBwUXfzPkrwHxH0We7jNQqzFLw9np2UgwQrboBEcgwUoxnDf vI1Dm8tO9zcdPxdXr/mVUMTJgqiPM0RyinEcDU2pfghkeRXVA4+7e7ucJOQwgvpD 6dfz672K4tB2bNHTWNrrsBqxVagUBS5Z9FdBj90j983FJYNVE6uNuc2lsjeWc5VL 7OFe1sEURtUuHrqhOj7l =vuUW -----END PGP SIGNATURE----- --Apple-Mail=_8935A690-5D2F-4271-AB81-E4E9D5D145BA--