PIE/PIC support on base

[Shawn Webb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On November 5, 2014 7:26:12 AM EST, Konstantin Belousov <kostikbel at gmail.com> wrote:
>On Wed, Nov 05, 2014 at 12:48:55PM +0100, Baptiste Daroussin wrote:
>> On Wed, Nov 05, 2014 at 11:26:14AM +0200, Konstantin Belousov wrote:
>> > On Wed, Nov 05, 2014 at 10:02:15AM +0100, Baptiste Daroussin wrote:
>> > > On amd64 WANTS_PIE will be useless as we can easily activate PIE
>on every places
>> > > For i386 we would propably prefer cherry picking the what we want
>to see built
>> > > with PIE. Don't know for other arches.
>> > >
>> > > So here is what I do propose:
>> > > if MK_PIE=no: no PIE at all
>> > > if MK_PIE=yes:
>> > > - on amd64/(platforms without performance penalty): build
>everything with PIE
>> > >   from libs to prog
>> > See below.
>> >
>> > > - on i386/(platforms with performance penalty): build with PIE if
>WANTS_PIE
>> > >   is defined.
>> > >
>> > > So the difference with the previous approach are:
>> > > - No way to opt out PIE for a single binary either totally
>disable or enable (I
>> > >   have encountered no binary so far in the base system which
>fails with PIE
>> > >   enabled - again only tested on amd64)
>> > > - Activate PIE for both binaries and libraries (no reason not to
>include
>> > >   libraries)
>> > What does it mean 'PIE for library' ? There is simply no such
>thing.
>>
>> Sorry I badly explained, I was meaning PIC for libs PIE for binaries.
>> >
>> > Also, I strongly oppose compiling everything with PIC, even on
>amd64.
>> > I described somewhere else that using PIC code changes symbol
>lookup
>> > rules for binaries.  So despite not having performance impact, the
>> > thing does impact runtime behaviour in subtle ways.  The most
>affected
>> > programs are those which support dynamic modules.
>Please do not ignore this ^^^^^^ issue.
>

Can you go into detail what those changes are?

>> >
>> > Also, what is the state of static binaries + PIE ? Do our binutils
>> > support this at all ? The csu is definitely not ready for
>'everything
>> > PIE'.
>>
>> Only dynamic binaries will receive PIE support (and in case of using
>an
>> INTERNALLIB will link to the libbla_pic.a) static ones will remain
>non PIE.
>
>And what about libX.a libraries, required by those static binaries ?
>It is wrong to compile the .o files for those static libraries in
>pic mode.
>
>More, take look at things which are done with -DPIC, e.g. in the
>lib/libc/sys/stack_protector*.c.  There, it is critical for
>correctness.
>
>
>_______________________________________________
>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"

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI8BAEBCgAmBQJUWh8pHxxTaGF3biBXZWJiIDxsYXR0ZXJhQGdtYWlsLmNvbT4A
CgkQaoRlj1JFbu7dvA//UsGATM6oO3Wutl6AeD17GyAd3b8LcYnxeF2mRV7EWwn+
o0I2Riact18cjO8VvCKqb3PGDdiARJK9Qi7kcJz2zQeMg6CvNWKfXBZ+W3Fp5KeC
8dhFaw+vzxG/FaAE/ZfsyUJhjB2kDWPrMqqoui1HNWG3AG8P92r7XEphs3XMX5+s
tS68r1P9C02q+jI/GgIyyNmReBlRKdAN7g05vW08TfGSPiI2SG5pd6q7zHn/iVXX
eHiHZ06mS3ljpm6rTfrNZlUqX8sPH8/wGGGcR9zWlHhxT8fvdY+2jZ59R2ddCcHu
pRZ4oZ3RTMFCh7vBCPPC1FjjzWmp6CNnRu51Ud+w2Yau0bt9AyAcplCCEhiO+jDI
ZjWTgkLMnZRyarnHqaF7eHtKRifKL29k/D4Uc3eL5mK8UYHtbDIAAlNAYWdDecwt
E8lYT4VUWnw7/slGRt6Zv+lbieEk0Q5iHyNaoE28BZnOLC6smLeNd1CAz7bOradb
8c2C5NH7oOWqV9ZarX2oSgBQdFLhRRTLAKUFBbDY22nRBpLdNKCF48MIzds5ZCo8
dlxSM6DjnJQF4dtIM9VL6zr3o9SqCLn1mGqkAABAYvnTo/zBMJ3u21ayzWYMYAs6
NWD9a/+Iu3dYP4uyi2139/Pvwy6C/Riuiag4iVk+/qc9m42FnNAPzsPgHIEtgRY=
=HscB
-----END PGP SIGNATURE-----