I agree that this is a heavyweight solution - but it is appropriate in
the case of encryption filters or other filters that carry out the sort
of data modifications you describe in your original note.
The simpler solution is to use non-cached I/O. For many instances that
is sufficient.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Thursday, November 18, 2004 6:18 PM
To: ntfsd redirect
Subject: RE: [ntfsd] IoCreateFileSpecifyDeviceObjectHint …
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