Force PHP binaries to link with non PIC objects on x86_64

[bogdanandone]

No description provided.

[dstogov]

why do we need this?

[bogdanandone]

the line forces libtool to compile both static and dynamic objects if sapi binaries are in the target;
without this line libtool compiles only PIC objects

[cjbj]

Was this tested with --enable-dtrace?

[dstogov]

I suppose no.

On Thu, Nov 26, 2015 at 12:46 AM, Christopher Jones <
notifications@github.com> wrote:

Was this tested with --enable-dtrace?

—
Reply to this email directly or view it on GitHub
#1650 (comment).

[bogdanandone]

I did a build with --enable-dtrace configuration flag. I can confirm the followings:

• Zend/.libs/zend_dtrace.d.o (the PIC object) is still there
• Zend/zend_dtrace.d.o (the non PIC object) is generated (due to the patch)
• Zend/zend_dtrace.d.lo (libtool helper object) has references to both PIC and non PIC object, as expected
• php-cgi still works

Unfortunately I am unable to have a real dtrace run as I don't have an Oracle Linux platform.

[cjbj]

Dtrace is available on OS X too, if that helps.

[dstogov]

Why do you think, non-PIC build will prevent dtrace from work?
Also for "darwin" we already use non-PIC objects.
On Nov 27, 2015 2:04 AM, "Christopher Jones" notifications@github.com
wrote:

Dtrace is available on OS X too, if that helps.

—
Reply to this email directly or view it on GitHub
#1650 (comment).

[bogdanandone]

OS X platform not available...
Theoretically speaking dtrace static or dynamic linkage should not be impacted as the patch is not replacing PIC objects with non PIC objects; dtrace PIC objects are still there; if dtrace needs Zend/.libs/zend_dtrace.d.o PIC object it will find it.
Even more, even if Zend/zend_dtrace.d.lo keeps reference to both objects, libtool will take into account by default the PIC version for linking; actually I didn't find a clean way to instruct libtool to link with static objects.

[laruence]

doesn't "--with-pic Try to use only PIC/non-PIC objects default=use both" work?

[dstogov]

It looks like libtool compiles each C file teice (with -fPIC and without),
but then use PIC objects anyway.

On Mon, Nov 30, 2015 at 9:13 AM, Xinchen Hui notifications@github.com
wrote:

doesn't "--with-pic Try to use only PIC/non-PIC objects default=use both"
work?

—
Reply to this email directly or view it on GitHub
#1650 (comment).

[remicollet]

Notice: some linux distro requires to use PIC object for security reason.
E.g. https://fedoraproject.org/wiki/Packaging:Guidelines#PIE

[laruence]

then maybe we should make this can be controlled by configure option like --(en|dis)able-pic?

[weltling]

Thanks for the info, Remi.

Ping @oerdnj, what are the Debian policies on enforcing PIC?

@bogdanandone were you keen to study yet more the security implications? In Windows builds, /DYNAMICBASE is enabled always and cannot be disabled. IMHO this PR should be reevaluated from the security angle. The suggestion of @laruence to have a switch, probably that is disabled by default, could be an option.

Thanks.

[bogdanandone]

Actually I was wondering why is PHP systematically using PIC objects everywhere ... Thanks to Remi now I have an answer :-) .

From your notes I understand that the capability to relocate binaries for security reasons should be preferred by default before performance.

I will look how --with-pic flag could be used. For now they have a strange behavior on my configuration so I have to go in a deeper investigation.

Thanks.

[oerdnj]

Not entirely sure that Debian has PIC as a system-wide policy, since Debian Hardening is still not release goal. But we definitely want have ASLR as much as possible for the code exposed to the wild wild internet. I think this would cause a lot of frowning in our security team and I would most probably revert this patch for Debian builds to have a PIC (and possibly PIE) build.

https://wiki.debian.org/Hardening