Modern versions of the gcc compiler are able to build position independant
executables on Linux (and possibly other) platforms. Position independant
executables (PIEs) provide additional security benefits against software
based attacks on known vulnerabilities, by randomizing the address locations
of the executable code. This helps to greatly reduce the likelyhood of
a malicious attacker successfully exploiting a known security vulnerability.
PIE support pays a slight performance cost however, and the decision to
use it for a given application or not, depends on how critical the performance
of the application is, and how great the performance cost is when the app
is built as a PIE.
Applications which are network facing servers are prime candidates for
optionally being built as PIEs, as are network clients and SUID apps.
Several applications included in Xorg packaging are daemons,
or SUID apps, of which can benefit from being built with PIE
This bug is a tracker bug to track PIE requests for enhancement
in X.Org X11.
Here is a link to some documentation on PIE, which may be useful to whomever
takes up this task:
When implementing PIE support, it would be nice to be able to choose
which apps should get PIE, and which should not get PIE. If there are
measureable performance loss in the X server with PIE for example, then
it might be best to default the X server to non-PIE and let the builder
override the defaults for a particular application.
Here are the applications I think would benefit the most from PIE support:
Having a generic PIE flag, enabled by imake by default if the system gcc
supports PIE, and then individual boolean PIE flags for each app might
make the most sense.
causes the following to be set:
Then you can take the defaults, or override a particular executable to
be non-PIE if desired, etc..
Just some implementation thoughts...
This should be much easier in the modular tree, where you can add it to
configure.ac for only those programs it's worthwhile to use it in.
aiming this at 7.1. but this should really be trivial with autotools, no?
probably not going to make 7.1, counts as a feature at this point.
(In reply to comment #5)
> probably not going to make 7.1, counts as a feature at this point.
Feature, moving to 7.2.
No longer interested in tracking this feature, closing...