On Mon, Dec 02, 2002 at 11:54:20AM +0900, Bang Jun-Young wrote:
> > > 
> > > > The next time the same binary is executed, ld.elf_so checks if there are
> > > > modifications in objects by comparing md5 checksum, starting address, etc.,
> > > > and if not, it reads a RelCache file and mmaps (overlays) it on the 
> > > > appropriate memory region.
> > > 
> > > I.e. if the executable doesn't have the md5 checksum set in the md5
> > > section (newly installed, not yet prebound), the executable has been
> > > modified since it was prebound (again, newly installed), and probably
> > > others ("etc." above), it does not match.
> 
> Right.

So, the checksum is effectively just used as a "magic number", AFAICT.  Since
it is not actually checked at runtime, it's really hard to see what benefit
this has over either a simpler checksum that _is_ checked or a random number
that need never be computed from the (potentially quite large) input at all.

> > In that case, what is the point of using an MD5 checksum?  A random number
> > of the same length would serve equally well.
> 
> Since MD5 checksum is known to have very good distribution (i.e. a lot less
> hash collision), it's the safest method to check for validity of the file.

You're concerned about collisions between 128-bit random numbers?  I'm not
sure if you're serious, but if you are, I'll point out that you can easily
enough add some bits -- a property that MD5 doesn't really have.

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud