prelink performance gains [summary]

Jan Kratochvil jan.kratochvil at redhat.com
Wed Oct 16 07:44:06 UTC 2013


On Wed, 16 Oct 2013 09:20:02 +0200, Dridi Boukelmoune wrote:
> I understand, but what bothers me isn't the prelink bug but prelink
> itself being installed by default (for what it does regardless of the
> bug).

What exactly bothers you?  It (generally) speeds up programs startup.

As a summary I see prelink has some bugs:
 * -y has false mismatches: https://bugzilla.redhat.com/show_bug.cgi?id=666143
 * %preun does not unprelink: https://bugzilla.redhat.com/show_bug.cgi?id=841434
 * It has a bug that in some cases it slows down the startup (seen on mplayer).
   https://lists.fedoraproject.org/pipermail/devel/2013-October/190274.html
 * It possibly should disable itself to run on very low memory systems as
   there can be running multiple copies of prelinked/unprelinked binaries.

Plus prelink is affected by bugs in other packages:
 * cron: It should not run cron.daily(+weekly...) if the user is not idle or
   if the system is running on battery
 * systemd should restart daemons which are updated.  For example
   openssh-server restarts itself in %postuninstall but not all packages do so.
 * tripwire/rkhunter/...: System verificators should use 'prelink -y'.
 * FIPS: It should unprelink the whole system if it needs it that way.

There is remaining security request to have all binaries PIE. IIUC it is for
the case of untrusted files stored at local filesystem accessed by for example
gzip where exploits could be reduced by having for example even gzip PIE.
I do not find it worth the small performance hit but people may disagree.


Jan


More information about the devel mailing list