On Sat, 23 Jun 2007, John Summerfield wrote:
<snip>
> (final) linking is done when a program loads. The idea of prelinking is to do 
> this beforehand, so loading programs proceeds more quickly.
>
> It provides no benefit at all once a program's up and running. I expect it to 
> be most useful in desktop environments, and of least use in dedicated 
> database servers.

The prelink docs etc claim that it simply alters the base addresses used 
by each shared-library to avoid clashes and so avoid 'costly' re-location 
on-load.

It cannot be used with 'per-process library address randomization' and so 
it needs to do it's own faked randomisation and be run periodically to get 
some of that security back.

Apparently PIC/PIE executables don't use the prelink data anyway on 
RHEL/FC derived systems so they can use the randomized-address load 
feature.

See:

    http://en.wikipedia.org/wiki/Prelinking
    http://people.redhat.com/jakub/prelink.pdf
    http://lwn.net/Articles/190139/

for some details

However since the libs are changed the mapping of them is unlikely to be 
sharable with ones before the changes so causing multiple copies to need 
to be kept in the system buffer-cache.  Or maybe it is only the bits that 
got changed by prelink which won't be shared but I doubt it (since the 
preliniked libs have different inode-numbers).

Not a big problem if you have more memory than you will ever need of 
course...

> It's not a new idea; we used to do something similar with IBM's OS in the 60s 
> and its early OS/VS successors in the 70s.

I'm not convinced the any possible speedup is worth losing the 
address-space-randomization feature.

  -- Jon