On Tue, Dec 18, 2007 at 12:23:25AM +0200, Elad Efrat wrote:
> 
> Okay. I gave this some thought. First, I think we need to better define
> the interaction between NFS (and probably remote file-systems in
> general) and Veriexec. IIRC, we did this a long time ago, but we
> really should make it clear and documented. We're also missing the
> per-page fingerprints that make it "easier to trust" files from a system
> you have no control over.
> 

There are two sides to the NFS equation when it comes to veriexec:

1) Server side, this presents some issues because we usually hook into
   the VOP layer for read/write checking.  Unfortunately the NFS
   server does not use the VOP calls when it gets read/write requests,
   the server code pages the requested part of the file into memory
   and then pushes it out to the client.  From (possibly incorrect)
   memory, the open code path is different to most other file systems
   too.

2) Client side, does use the VOP calls so the veriexec checks should
   just work but with the caveat that the server needs to be trusted
   absolutely.

I am sure that the per-page checking I would like to get in would
address the issues on both sides.  I need to get back to the unified
iodone call - after talking with Chuck a while back I understand
things a bit better, I need to update my tree and push another patch
out.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."