On Tue, Oct 11, 2005 at 12:43:38AM +0200, Hubert Feyrer wrote:
> 
> Thanks for working on this, it sounds like a very nice addition.
>

You should thank Thor Lancelot Simon (tls) really - it's his
suggestion from a long time ago.  I have had a working implementation
for a while but I was not happy with adding yet more bits to the vnode
structure but Elad's work made that problem go away.

> Can you give any numbers on the speed impact of this?
> E.g. for startup times of (say) firefox?
> 

I will work on getting some numbers though the start up time is going
to be hard to pin down exactly.  I expect the first start up will get
hit with twice the hashing time (once for the overall file hash and
one for the individual text pages) but once this is done the impact
should be minimal as the overall fingerprint result and the page
fingerprints are stored in memory, it would only pages that get paged
in from backing store that would be affected.  If you have a machine
with sufficient resources then the operational impact should be fairly
minimal (I expect) as most things will stay memory resident but for a
machine that is under memory pressure and is doing a lot of
paging... well... using page fingerprints will make a bad situation
worse (i.e. even slower).  The per page fingerprinting will be
configurable on a file by file basis in the veriexec control file, it
will not be a global thing.  It is intended to protect files that are
on storage that is not under the direct control of the kernel (NFS
shares or SAN disk for example) where the file contents can be
modified by a third party without the kernel being involved.

-- 
Brett Lymn