Hi Ravi,
My AV, minifilter and legacy, depends blindly in paging writes, mainly for
performance reasons.
Our AV´s caching policy needs to know in create & cleanup path whether the
file has been modified. When the file is dirty, cache information is
discarded and the file is scanned. Obviously If I am not able to see paging
writes I don´t know whether the file has been modified or not, as
IrpSp->FileObject->Flags & FO_FILE_MODIFIED | FO_FILE_SIZE_CHANGED) are
useless here.
AV products can not be released without a file caching module. Is there any
alternative to detect file modification in this situation?
Thanks.
mK.
Basically you are suggesting that every user handle be proxied with another
file object that is sent down the stack.
I guess this works, but is quite a heavy solution. Note any i/o the
encryption filter itself has to issue (i.e. Filter A), should also be done
carefully - i.e. either IoCreatFileSpecify*() is used with non-cached i/o or
the file-object is proxied as you describe.
I would also be interested in hearing from antivirus guys since they can
miss paging writes this way. Do AV filters depend on seeing a write of some
sort before scanning? Basically it sounds like issuing cached i/o by a
filter lower in the stack via a targetted file handle (where the create is
not seen successfully by the upper stack) seems like a bad idea to me in the
first place. Non-cached i/o should be fine.
Ravi
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Thursday, November 18, 2004 8:01 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] IoCreateFileSpecifyDeviceObjectHint …
Hi Rod,
Old age catches up with all of us at some point…
The VM system is really very simple here: it associated the cached state,
via the section object, using the SectionObjectPointers Structure. To
dissociate the two, use different SectionObjectPointers structures.
To build on Ravi’s example, Filter ‘A’ would receive an IRP_MJ_CREATE for
“foo.txt”. Filter ‘A’ then creates a new file object
(IoCreateStreamFileObjectLite probably). This New File Object (“NFO”) is
sent to Filter ‘B’ and then Filter ‘B’ forwards it to the file system.
The file system associates its own section object with NFO. Should Filter
‘B’ open “foo.txt” it will also use the same SectionObjectPointers structure
as NFO - and hence the same cached state. But the clear version of the file
is maintained by Filter ‘A’ in the SectionObjectPointers information
associated with the original file object.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April 4,
2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Thursday, November 18, 2004 7:56 AM
To: ntfsd redirect
Subject: Re:[ntfsd] IoCreateFileSpecifyDeviceObjectHint …
Tony,
could you expand? What are you proposing that we do?
I’m not current enough in this space and the neurons that used to know are
backed up on tape somewhere: is it feasible to supress the use of the cache
for files (whether opened by IoCreateFileSpecifyDeviceObjectHint or
something else)? or can you spoof the cache manager into thinking that this
is a ‘different’ file?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe send
a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
-----Original Message-----
From: Ravisankar Pudipeddi
Sent: Wednesday, November 17, 2004 4:19 PM
To: ‘Windows File Systems Devs Interest List’
Subject: IoCreateFileSpecifyDeviceObjectHint …
I wanted to draw attention to this interesting thing about this API:
Currently, 2 filters are loaded as below (B is below A).
Filter A
Filter B
Assume A is an encryption filter. B is a different filter. B opens a file
foo.txt via IoCreateFileSpecifyDeviceObjectHint() and reads from it
- it reads encrypted data, but doesn’t care. A cache map is initialized and
a section created and this file object now will be used for paging i/o. Now
the file is closed, but Mm doesn’t release the reference on the file object.
Next the user comes and opens foo.txt, and reads from it. Since it’s a
cached read, Mm will fault in the page. However the page in will be using
the file-object obtained above. However since the file-object is obtained
via IoCreateFileSpecifyDeviceObjectHint(), the i/o bypasses Filter A. The
cache is now polluted with encrypted data and the user sees encrypted data.
You can consider other scenarios here: A is an antivirus filter and B does
this open and read. Now paging i/o (including paging writes) will bypass
filter A. Filter A may infact think the file was never written to
- I’m guessing that this is mitigated by the fact that probably antivirus
filters would potentially always scan when the file was opened for write
access even if they miss paging i/o … Or maybe this is not a big enough
scenario.
The question is - is this a well known issue?
Do any of the filters see this as a problem today? If not, why not?
Ravi
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/