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
[-- Attachment #1 --]
So,
WITH_PIE -> MK_PIE == yes.
This says “for the things that support PIE, build them.” 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’s “USE_PIE"
What does that mean? There’s 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’s not
a user accessible part. This suggests that we could rescue it from this obscure
corner.
It’s also used in ports to enable a features, but in a different way than we’re 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={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’m 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=no, which is what lead, in part, to the NOxxx jihad of the late 1990s. I’d
rather like to avoid any new NO options. Oh, and I’m glad YES_HESIOD is now in
the dustbin of history.
If I were designing things, I’d 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/… But these uses are transitioning
to MK_xxx={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>
>
>
> Except Baptiste, what do you all think about USE_PIE versus WITH_PIE ?
>
> On Thu, Oct 16, 2014 at 11:37 PM, Bryan Drewery <bdrewery@freebsd.org>
> wrote:
>
>> On 10/16/2014 5:15 PM, Shawn Webb wrote:
>>>
>>>
>>> On Thu, Oct 16, 2014 at 5:59 PM, Jeremie Le Hen <jlh@freebsd.org
>>> <mailto:jlh@freebsd.org>> wrote:
>>>
>>> On Thu, Oct 16, 2014 at 8:21 PM, David Carlier
>>> <david.carlier@hardenedbsd.org
>>> <mailto: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 <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 ?
>>>
>>> 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.
>>>
>>
>> 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.
>>
>>> 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.
>>>
>>> Thanks,
>>>
>>> Shawn
>>
>>
>> --
>> Regards,
>> Bryan Drewery
>>
>>
> _______________________________________________
> 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"
[-- Attachment #2 --]
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35058403-E24F-4243-ABD1-CE82A1764977>