On Fri, Nov 22, 2002 at 03:18:28PM +0900, Bang Jun-Young wrote:
  | Here's the summary of what I have been thinking about ELF prebinding
  | since a couple times of objections from people against my previous
  | not-good implementation ;-):

some minor issues.


  | - Every binary, including executable and shared object, has .csum
  |   section inserted by ld(1) at compile time. It is 32-bit long and
  |   used for storing checksum (CRC32) of the binary.

i'd prefer md5 or sha1 as a hash.


  | - Actual prebinding and prerelocation is done by ld.elf_so(1). After 
  |   ld.elf_so(1) loads a binary for the first time, it creates a disk
  |   file in /usr/libexec/reloc (say it "cache") and writes all of the

/var/db/reloc (persistent) or /var/run/reloc (lost at reboot) are
better locations...


  |   relocated GOT and PLT sections in memory to the file (checksum and
  |   other necessary information as well). In any subsequent execution
  |   of the same binary, ld.elf_so(1) no longer performs relocation.
  |   Instead it loads cache from the disk file previously created and
  |   compares cache information and in-memory data. If they don't differ,
  |   it patches GOT/PLT pointers so that they point to locations in the
  |   cache. But if they differ, ld.elf_so(1) will do the same job. 
  | 
  | - As time goes by, there will be more caches stored in /usr/libexec/reloc.
  |   If needed, elfreld(1) daemon regularly check if they are still valid, and
  |   removes invalid files. Or you can remove all of them, and ld.elf_so(1)
  |   will perform the same job again for each binary it loads.

do we even need an elfreld daemon?  does it matter if the cache grows.


  | Advantages of this method include:
  | 
  | - Minimal modification to binary. Only .csum is inserted and it is
  |   ignored by old ld.elf_so(1).
  | 
  | - No additional executable is required (elfreld(1) is fully optional).
  | 
  | - It doesn't break ELF semantics. Cache is just an image of the in-memory 
  |   data after relocation is done.
  | 
  | - It is much simpler and can be (significantly) faster than our
  |   competitor's implementation (prelinking in Red Hat 8.0). You don't
  |   even have to bother to run prelink against newly created binaries in
  |   the system regularly. Everything is automagically done by ld.elf_so(1). 
  | 
  | - Better CPU cache utilization is possible, since it is likely
  |   that all the GOT/PLT entries for a binary and shared objects it
  |   depends on are stored together in a single page, or at least, adjacent
  |   in memory. 
  | 
  | Disadvantages of it include:
  | 
  | - When ld.elf_so(1) loads a binary for the first time, it takes more
  |   time (rarely, much more) to get it done, since it creates and write
  |   cache to disk.
  | 
  | - Security considerations (?).
  | 
  | - (please put your comments here ;-).
  | 
  | Comments would be appreciated, 

sounds good otherwise...