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
