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>