On Mon, Mar 22, 2004 at 01:36:21PM +0300, dlagno@mail.nnov.ru wrote:
> 
> Log messages about these files will be issued only once.  With this patch 
> you can for example rebuild your system with tools without junking up 
> logs.
>

Sounds like a good idea.  Preventing the spamming of the logs could be
a useful thing to have.
 
> Comments?  Could it be committed?
> 

Looks interesting.  I will have a better look at the code, try it out
and if it works well commit it.

> Also when I inspected current veriexec implementation I see that inode to 
> check fingerprint for is searched in a linear list (probably few 
> thousands entries long).  Is it for certain that this search is dominated 
> by calculation of fingerprint?
> 

The thing that saves the performance hit of searching the list is that
on a hit the fingerprint comparison result gets saved, currently, in
the vnode structure.  As long as the vnode is not recycled then the
list is not searched so the list search time should not dominate.  One
thing I had thought of doing was possibly reordering the list when a
fingerprint is found on it, take that fingerprint and put it at the
head of the list.  That way the most often used executables would be
near the head of the list.  The other alternative is to build a hash
table to cut the amount of linear searching down, though getting the
table balanced could be interesting since (without looking - I may be
wrong here) I expect that most of the executable inodes will be
clustered close together given how they are normally installed, in
batches.

Probably the worst thing from a performance point of view is opening a
file since that will traverse both the file and the exec list looking
for that file.  I am looking to address this by changing the way that
the verification of shared libraries is done.

I am still working on verified exec, there are plenty of things that
could be improved.

-- 
Brett Lymn