On Sun, Dec 01, 2002 at 10:20:34PM -0500, Thor Lancelot Simon wrote:
> 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 the future, it might be used to check if the file is modified from the
distribution.

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

At first I decided to use CRC32, but some people pointed out that it's
too weak to be used as hash. If CRC32 was used, could you explain how to
avoid hash collision between files? Although collision would very rarely
occur, but people want a perfect one.

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>