Subject: Re: RelCache (aka ELF prebinding) news
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-userlevel
Date: 12/03/2002 18:28:47
On Tue, Dec 03, 2002 at 02:46:52PM -0800, Jonathan Stone wrote:
> 
> .... I hate to blow my own trumpet here, but I do have some expertise,
> (even some professional reputation), in this area.
> 
> 
> I'd really appreciate it if someone could take the time to explain
> just what the application-level goal is, here: what uses this
> ``signature'' is expected to be put to, and what threats
> (non-malicious errors during data transmission? Malicious modification
> and recomputation of a matching CRCs?) the application is, or is not,
> expected to protect against.
> 
> I'm afraid I've lost track of that, amongst all the heat and noise.
> 
> If we can refocus on what's really wanted, on what threats are inside
> the scope of the problem and which are outside, then it'd be
> relatively straightforward for a number of the regulars here to
> recommend an appropriate algorithm.  And even to explain why other
> algorithms aren't quite so appropriate.  
> 
> So... what *are* we trying to accomplish? 

Bang just wants a unique identifier for a given shared object file that
has the property that it depends on the file contents (I already
recommended a 128-bit random number, but evidently people want to be
able to naively diff their "stamped for prebinding" .so files and
see that they are the same).

Even a perfect 32-bit identifier isn't good enough, by itself.  I strongly
suspect that a 32-bit identifier stamped into the file, plus information
from the metadata, probably is, in the real world.  The 64-bit identifier
that Bang is using now, consisting of the CRC-32 of the file followed by
the Adler-32 of the file, is probably good enough all by itself but it
seems silly to not use the file size and metadata to further reduce the
chance of collisions no matter how the identifier is chosen.

The sole purpose of this identifier is to ensure that ld.so does not
mistake one legitimate .so file for another.  Deliberate attempts to
generate hash collisions are beyond the scope; this is not a security
function, we simply want reasonable assurance that the prebinder will
not hand you the symbols for the wrong shared object file because they
happened to have the same unique identifier computed from their contents
and stamped into them.

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