On Tue, 11 Oct 2005, Brett Lymn wrote:
> 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.

``Thanks, Thor! Thanks Elad'' :-)


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

I see... so the question that arises from that then is, how much does the 
fingerprinting affect the memory footprint of the program?

Also (I never played with veriexec), when do the per-page fingerprints get 
created - I guess once on system install, and then reside in immutable 
files?


  - Hubert