On Fri, Nov 01, 2002 at 11:55:49AM -0800, Bill Studenmund wrote:
> 
> Uhm, read the thread please.
> 
> The md5 hash is calculated the first time a program is loaded. The hash is
> kept in-core with the vnode. As long as the node stays in-core, the hash
> is still cached. Thus we aren't hashing everything every time we run.

This, to me, is the major flaw of this mechanism.  Files come in and out
of our kernel in pages; even if you validate the whole thing at startup,
there's just nothing whatsoever preventing someone from shuffling a page
out under your feet so that the next time it comes in, it'll be different.

Implementing per-page hashes in the vnodepager would seem to be the only way
to really get this right; without it, honestly, I trust a simple if statement
about the schg bit quite a bit more than a bulky hash-validation mechanism
that's vulnerable to all of the same attacks.  Note that adjusting the
semantics of the schg bit so that it did the other things this code does
(e.g. the special cases for interpreters, libraries, etc.) would be quick,
easy, and end up with a system that was no _less_ secure than one using
this cached-hash mechanism and, arguably, simply because of the smaller
amount of code involved, probably _more_ secure.

Using signatures opens up other possibilities, for instance the possibility
of allowing appropriately-signed executables to do things like replace the
hash list or adjust the file flags.  Then you'd really have something useful;
but used for the current purpose, the verified exec code really seems to offer
only the dubious advantage of great complexity when compared to the existing
file flags mechanism.  It would seem to offer the advantage that it can be
used with filesystems that don't support flags, like NFS, but that's actually
not so, because the caching behaviour makes it too dangerous to use it across
the network at all.

Thor