Looking at bug https://bugzilla.redhat.com/show_bug.cgi?id=679880 it seems that prelink does make things a bit faster if run on the live image at compose time, as well as saving lots of memory if run for more than a day (when the prelink cron kicks in).
Anyone have objections to adding a prelink call to the end of the live base compose? Or should we just disable it entirely?
Thoughts?
kevin
On Sun, 27 Feb 2011 21:13:00 +0100, Kevin Fenzi wrote:
Looking at bug https://bugzilla.redhat.com/show_bug.cgi?id=679880 it
[...]
Anyone have objections to adding a prelink call to the end of the live base compose?
To run prelink at the compose time is a great idea.
BTW for the full picture - if you run non-prelinked binaries at least their libraries get randomized memory location. With prelinked libraries they are no longer randomized. This is a better target if some exploit exists.
While normal systems have each their own prelinked addresses which the attacker usually cannot guess the distributed prelinked LiveCD will have addresses publically known to everyone.
OTOH exploit-sensitive applications are already PIE (Position Independent Executable; gcc -fPIE -pie) and such apps have the libraries randomized on each run even despite they may be already prelinked.
Or should we just disable it entirely?
non-prelinked binaries have needless performance and runtime memory costs.
Thanks, Jan