Re[2]: Tracking file objects

Ged,

For the upper file objects which you own, you have setup the FsContext
and FsContext2 pointers to point to your own control structures. What
you can do is setup the first 4 bytes of the FsContext2 structure to
point to a unique signature for your file objects. This way, perform
validation on the pointer and then evaluate the first 4 bytes to
determine if it is your file object or not.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: “Ged Murphy”
To: “Windows File Systems Devs Interest List”
Sent: 1/22/2015 5:26:02 AM
Subject: RE: [ntfsd] Tracking file objects

>Yeah I have a similar setup, the lower file objects are no problem.
>What I’m referring to is in the isolation model, we obviously have to
>ensure that the FO’s we own never go below our filter. So how do we
>determine which upper file objects are ones we own, and which are one
>that the FSD owns.
>
>In normal (non-isolation) filters, most people make a decision in the
>create callback and set a streamhandle context for the FO. They can
>then use FltGetStreamHandleContext in all the other callbacks to check
>if it’s a FO they’re interested in.
>
>What I’m wondering is In the isolation model do people do things
>differently? Is it preferred to just keep a linked list of all the
>upper FO’s we own and check this list for every callback, or do I just
>use FltSetStreamHandleContext in the create callback on my own FO and
>check it as usual in all the others.
>
>I realise I’m probable overthinking this but it’s a question I keep
>asking myself and haven’t come to a decision on ‘best practice’
>
>Ged.
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
>Sent: 22 January 2015 12:06
>To: Windows File Systems Devs Interest List
>Subject: Re:[ntfsd] Tracking file objects
>
>> When implementing the isolation model, what’s the preferred way of
>> tracking file objects that we own?
>
>In any filter I usually find it handy to have my StreamHandleContexts
>in a linked list off my StreamContexts and my StreamContexts off my
>VolumeContext. This should give you all you need to be able to find all
>the lower file objects (since your lower file objects are in your
>StreamHandleContext, right).
>
>Unrelated to this but when you are working out your navigation you need
>to bear in mind the exigies of oplocks which require you to be able to
>traverse all the children (to break an oplock to allow a directory
>rename to work).
>ISTR that there are also cases when you need to be able to traverse
>upwards as well.
>
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

Yeah I thought about this route initially, but then how unique is a unique signature? I realise it’s a million-to-one chance, but it’s possible that some other filter (or 3rd party file system) uses FsContext2 and the first 4 bytes may match up at some point.

Considering the file object address is guaranteed to be unique, isn’t that a better option?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of PScott
Sent: 22 January 2015 14:59
To: Windows File Systems Devs Interest List
Subject: Re[2]: [ntfsd] Tracking file objects

Ged,

For the upper file objects which you own, you have setup the FsContext and FsContext2 pointers to point to your own control structures. What you can do is setup the first 4 bytes of the FsContext2 structure to point to a unique signature for your file objects. This way, perform validation on the pointer and then evaluate the first 4 bytes to determine if it is your file object or not.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: “Ged Murphy”
To: “Windows File Systems Devs Interest List”
Sent: 1/22/2015 5:26:02 AM
Subject: RE: [ntfsd] Tracking file objects

>Yeah I have a similar setup, the lower file objects are no problem.
>What I’m referring to is in the isolation model, we obviously have to
>ensure that the FO’s we own never go below our filter. So how do we
>determine which upper file objects are ones we own, and which are one
>that the FSD owns.
>
>In normal (non-isolation) filters, most people make a decision in the
>create callback and set a streamhandle context for the FO. They can
>then use FltGetStreamHandleContext in all the other callbacks to check
>if it’s a FO they’re interested in.
>
>What I’m wondering is In the isolation model do people do things
>differently? Is it preferred to just keep a linked list of all the
>upper FO’s we own and check this list for every callback, or do I just
>use FltSetStreamHandleContext in the create callback on my own FO and
>check it as usual in all the others.
>
>I realise I’m probable overthinking this but it’s a question I keep
>asking myself and haven’t come to a decision on ‘best practice’
>
>Ged.
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
>Sent: 22 January 2015 12:06
>To: Windows File Systems Devs Interest List
>Subject: Re:[ntfsd] Tracking file objects
>
>> When implementing the isolation model, what’s the preferred way of
>> tracking file objects that we own?
>
>In any filter I usually find it handy to have my StreamHandleContexts
>in a linked list off my StreamContexts and my StreamContexts off my
>VolumeContext. This should give you all you need to be able to find all
>the lower file objects (since your lower file objects are in your
>StreamHandleContext, right).
>
>Unrelated to this but when you are working out your navigation you need
>to bear in mind the exigies of oplocks which require you to be able to
>traverse all the children (to break an oplock to allow a directory
>rename to work).
>ISTR that there are also cases when you need to be able to traverse
>upwards as well.
>
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Ged,

Rod’s approach will definitely work for isolation drivers. But to
address your previous concern, as a filter driver you are sitting above
all the file systems in question and thus will be able to have first
access to the file objects, prior to them processing them. Thus checking
the magik number in the Ccb pointer to determine if it is your file
object, prior to sending it down the stack, will work just fine.

And yes, they ‘should’ only receive file objects which belong to them
but in the case we are discussing combined with a broken isolation
filter which inadvertently passes down their file objects to NTFS will
crash the system. In the end, as a filter you will be able to inspect
all file objects prior to them being passed to the underlying file
system.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: “Ged Murphy”
To: “Windows File Systems Devs Interest List”
Sent: 1/22/2015 11:04:59 AM
Subject: RE: [ntfsd] Tracking file objects

>So you’re saying in the PreCreate:
> - Create the lower FO (shadow file)
> - Copy the bits up to the upper FO
> - Create and initialize FsContext & FsContext2 for the upper FO
> - Call FltSetStreamHandleContext on the upper FO, and store the
>address of FsContext2 you just created
>- Release
>
>On all other calls:
> - Call FltGetStreamHandleContext on the upper FO to check if it’s one
>you own
>
>
>That was one of the original ideas I’ve been toying around with, the
>other option was a linked list of all the FO’s I own, and traverse the
>list on every call (instead of calling FltGetStreamHandleContext)
>
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
>Sent: 22 January 2015 17:47
>To: Windows File Systems Devs Interest List
>Subject: Re:[ntfsd] Tracking file objects
>
>I must admit I have never relied on magick numbers. I’m more brutal, I
>just make my Ccb (FsContext2) a StreamHandleContext on the upper file
>object.
>
>in in PreCall you get the StreamHandleContext
>- If there isn’t one its not your file object
>- If it there is you can inspect it to see whether it has a lower file
>object.
>
>By contrast I make the Scb (FsContext) a StreamContext on the Lower
>File Object.
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>For our schedule of debugging and file system seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer