Subject: Re: New idea on ELF prebinding
To: Bang Jun-Young <email@example.com>
From: Luke Mewburn <firstname.lastname@example.org>
Date: 11/22/2002 17:48:43
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
| 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...