Date: Thu, 16 Oct 2014 22:23:04 -0700 From: Warner Losh <imp@bsdimp.com> To: David Carlier <david.carlier@hardenedbsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: PIE/PIC support on base Message-ID: <35058403-E24F-4243-ABD1-CE82A1764977@bsdimp.com> In-Reply-To: <CAMe1fxaEd4w2P_=HAGyW9x8QKqCQ1QF-c_FRv4A0B%2BmhUcN=%2Bw@mail.gmail.com> References: <CAMe1fxaYn%2BJaKzGXx%2Bywv8F0mKDo72g=W23KUWOKZzpm8wX4Tg@mail.gmail.com> <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> <5440489F.3080602@FreeBSD.org> <CAMe1fxYjHjJcyKCtuD5gEJ2urnyd6=suLL5nTWHJbGsn5fSUVg@mail.gmail.com> <CAMe1fxaEd4w2P_=HAGyW9x8QKqCQ1QF-c_FRv4A0B%2BmhUcN=%2Bw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 = <david.carlier@hardenedbsd.org> wrote: > ---------- Forwarded message ---------- > From: David Carlier <david.carlier@hardenedbsd.org> > Date: Fri, Oct 17, 2014 at 5:52 AM > Subject: Re: PIE/PIC support on base > To: Jeremie Le Hen <jlh@freebsd.org>, Baptiste Daroussin = <bapt@freebsd.org>, > Shawn Webb <shawn.webb@hardenedbsd.org> >=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 <bdrewery@freebsd.org> > 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 <jlh@freebsd.org >>> <mailto:jlh@freebsd.org>> wrote: >>>=20 >>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier >>> <david.carlier@hardenedbsd.org >>> <mailto:david.carlier@hardenedbsd.org>> 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 <bsd.prog.pie.mk <http://bsd.prog.pie.mk>> (which include >>> <bsd.prog.mk <http://bsd.prog.mk>>...) otherwise other >>>> binaries include <bsd.prog.mk <http://bsd.prog.mk>> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35058403-E24F-4243-ABD1-CE82A1764977>