Distinguishing file objects that you own in a layered FS

Hello,

I’m thinking of implementing a layered filesystem using a minifilter. I want to handle a only part of the namespace found on an existing volume. However, I am puzzled by one question.

Since I am taking ownership only for a part of the namespace, in a callback routine (for IRP_MJ_READ or IRP_MJ_WRITE) how can I distinguish between the file objects that I own and the ones that I don’t own? Do I just attach a stream context to the ones that I own? Do I try to recognize my FsContext by looking for a signature? How do you do it?

I intend on passing through the I/O on the file objects that I don’t own down to the underlying real file system.

Thanks,
Mark

If you own the fileobject, you’ve set up the FsContext and FsContext2
pointers in the pre-create processing and have not sent the request
further down the stack. That said, generally you set a signature in the
FsContext2 control structure, recognizing it in your handlers. The
FsContext structure has the FSRTL header so it’s best to set the
signature in the FsContext2 structure.

Also, be sure that these file objects are never sent to the underlying
file system for any request, you must handle all requests for these file
objects you own. If you do send them down, the underlying file system
will BSOD, at least the Microsoft file systems will.

Pete

On 9/10/2013 10:28 AM, xxxxx@gmail.com wrote:

Hello,

I’m thinking of implementing a layered filesystem using a minifilter. I want to handle a only part of the namespace found on an existing volume. However, I am puzzled by one question.

Since I am taking ownership only for a part of the namespace, in a callback routine (for IRP_MJ_READ or IRP_MJ_WRITE) how can I distinguish between the file objects that I own and the ones that I don’t own? Do I just attach a stream context to the ones that I own? Do I try to recognize my FsContext by looking for a signature? How do you do it?

I intend on passing through the I/O on the file objects that I don’t own down to the underlying real file system.

Thanks,
Mark


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


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

Pete, thank you for the quick answer.

That said, generally you set a signature in the FsContext2 control structure, recognizing it in your handlers. The FsContext structure has the FSRTL header so it’s best to set the signature in the FsContext2 structure.

How do I make sure I play nicely with other minifilters/layered filesystems? I am thinking of the risk of signature collision (using the same signature as another filter).

What kind of signature do you use in order to prevent this? Should I worry about it?

Thanks,
Mark

There is no way to guarantee that a collision wouldn’t happen but given
the fact that there are few layered file systems I wouldn’t worry about
a collision. Just don’t pick one of the Microsoft signatures or anything
‘close’ to it in form or value … I have yet to ever hit a collision
and have implemented several layered file systems that are in the field.

Pete

On 9/10/2013 11:03 AM, xxxxx@gmail.com wrote:

Pete, thank you for the quick answer.

> That said, generally you set a signature in the FsContext2 control structure, recognizing it in your handlers. The FsContext structure has the FSRTL header so it’s best to set the signature in the FsContext2 structure.

How do I make sure I play nicely with other minifilters/layered filesystems? I am thinking of the risk of signature collision (using the same signature as another filter).

What kind of signature do you use in order to prevent this? Should I worry about it?

Thanks,
Mark


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


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

Thank you, Pete.

So the idea is that I allocate my own CCB, store the pointer to it in FsContext2 and then when I receive a file object I hope that:

  • FsContext2 is a valid pointer
  • the pointed piece of memory is valid

Then I cast it as my CCB, looking for the signature in one of the fields of the CCB.

Did I get this right?

Thanks,
Mark

Correct but put your signature in the first 4 bytes of the Ccb structure
to minimize the chance of accessing a region beyond the buffer if it is
not yours.

You can see this in the FastFat code, look in the routine
FatDecodeFileObject().

Pete

On 9/10/2013 12:15 PM, xxxxx@gmail.com wrote:

Thank you, Pete.

So the idea is that I allocate my own CCB, store the pointer to it in FsContext2 and then when I receive a file object I hope that:

  • FsContext2 is a valid pointer
  • the pointed piece of memory is valid

Then I cast it as my CCB, looking for the signature in one of the fields of the CCB.

Did I get this right?

Thanks,
Mark


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


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

Well, in order to avoid the risk of signature collision I’ve actually set a FltMgr context (usually a stream context) on the FILE_OBJECTs that I own. This works as long as you initialize the FILE_OBJECT and set up the SCB properly before you set your context.

It feels a bit weird that you set your context in a stream context attached to an SCB you own, but since FltMgr has all the things you need to keep filters from touching your context you don’t need to reinvent the wheel.

AFAIK this is the MS sanctioned way to do this.

Thanks,
Alex.
On Sep 10, 2013, at 11:31 AM, Peter Scott wrote:

>
> Correct but put your signature in the first 4 bytes of the Ccb structure to minimize the chance of accessing a region beyond the buffer if it is not yours.
>
> You can see this in the FastFat code, look in the routine FatDecodeFileObject().
>
> Pete
>
> On 9/10/2013 12:15 PM, xxxxx@gmail.com wrote:
>> Thank you, Pete.
>>
>> So the idea is that I allocate my own CCB, store the pointer to it in FsContext2 and then when I receive a file object I hope that:
>>
>> - FsContext2 is a valid pointer
>> - the pointed piece of memory is valid
>>
>> Then I cast it as my CCB, looking for the signature in one of the fields of the CCB.
>>
>> Did I get this right?
>>
>> Thanks,
>> Mark
>>
>> —
>> 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
>>
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
> —
> 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

Alex, that is a great idea.

Thanks to both of you!
Mark