> - 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.

> - 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

Shudder.  This sounds like a security disaster waiting to happen.  All
of a sudden, most of your system security is dependent on one directory
keeping its sticky bit.  It is also vulnerable to someone writing
forged preloaded data there before the real executable with that hash
is run.  Anyone who can read the executable and thus discover its hash
can perform this attack.  (Note that this is not helped by using a
cryptographically strong hash instead of a simple CRC, nor is it helped
by removing the read bits from the directory.)

I also expect hash collisions in this directory if you use a hash only
32 bits long; the birthday count is only 64K, which is not implausible
if this is done for all executables.

In another message,

> I thought about MD5 as well, but it is too long to be used as a file
> name.

An MD5, expressed in hex, is only 32 characters (never mind something
more compact like base-254; in any base from 185 to 254, it's only 17
bytes).  You could express it in _binary_, even, and still use it as a
filename.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B