PIE/PIC support on base

[Warner Losh]

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 at hardenedbsd.org> wrote:

> ---------- Forwarded message ----------
> From: David Carlier <david.carlier at hardenedbsd.org>
> Date: Fri, Oct 17, 2014 at 5:52 AM
> Subject: Re: PIE/PIC support on base
> To: Jeremie Le Hen <jlh at freebsd.org>, Baptiste Daroussin <bapt at freebsd.org>,
> Shawn Webb <shawn.webb at 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 at 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 at freebsd.org
>>> <mailto:jlh at freebsd.org>> wrote:
>>> 
>>>    On Thu, Oct 16, 2014 at 8:21 PM, David Carlier
>>>    <david.carlier at hardenedbsd.org
>>>    <mailto:david.carlier at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141016/f4734199/attachment.sig>