I have defined some custom FSCTLs that my filter handles. Per documentation, I have used the ISV function code range. However this obviously does not prevent another ISV from using the same function code. How do people handle this?
Currently I put some magic data in the header of the FSCTL packets sent from user mode to the driver. If I don’t see this magic data, I assume that this FSCTL is intended for someone else and I send it down to the next driver in the stack and let them handle/fail it. So I don’t think I will stomp on anyone else. However do other people do this? It would be a bummer to have someone higher up in the stack fail my FSCTLs because they don’t understand the contents.
Thanks,
Matt
>I have defined some custom FSCTLs that my filter handles. Per documentation, I have used the ISV
function code range. However this obviously does not prevent another ISV from using the same
function code. How do people handle this?
By using a control device and sending all IOCTLs to it.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
I already use a communication port for general communication. The FSCTLs I have defined are file handle based FSCTLs and I would rather let the IO manager deal with handle verification, file object routing, etc. Should I just not do this?
xxxxx@yahoo.com wrote:
I already use a communication port for general communication. The FSCTLs I have defined are file handle based FSCTLs and I would rather let the IO manager deal with handle verification, file object routing, etc. Should I just not do this?
None of this would change. In your control device you would create a
symbolic link which would be opened by your user mode application to
obtain a handle. This handle would be used in the call to send the
IOCtls to your driver. You can specify an acl on the control device to
enforce security, etc.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hmm… I’m not sure I got this question right… " The FSCTLs I have defined are file handle based FSCTLs and I would rather let the IO manager deal with handle verification, file object routing "… Does this mean (a) that you want to send FSCTLs on a file handle (something like…‘secure delete *this* file’ or ‘encrypt *this* file’) or (b) that you want to open different handles depending on the caller and these FSCTLs would behave differently based on who opened the handle… ?
As far as know creating a device and sending IOCTLs to it is no different from filter manager’s communication port… the IO will come directly to your minifilter.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
[quote] Does this mean (a) that you want to send
FSCTLs on a file handle (something like…‘secure delete *this* file’ or
‘encrypt *this* file’)… [/quote]
a)
A control object is no different from the communication port. I already use that. In this case I want to take actions based on an actual file open that was already done on the caller. (Like FSCTL_GET_RETRIEVAL_POINTERS for example).
I suppose I could have the caller send the file handle to the control object who could do access checks, etc. but why bother? I would rather let the IO manager do all of this for me…
xxxxx@yahoo.com wrote:
[quote] Does this mean (a) that you want to send
FSCTLs on a file handle (something like…‘secure delete *this* file’ or
‘encrypt *this* file’)… [/quote]
a)
A control object is no different from the communication port. I already use that. In this case I want to take actions based on an actual file open that was already done on the caller. (Like FSCTL_GET_RETRIEVAL_POINTERS for example).
I suppose I could have the caller send the file handle to the control object who could do access checks, etc. but why bother? I would rather let the IO manager do all of this for me…
For file specific requests using already defines control codes you
should keep it as you have it. Your original query though had to do with
custom control codes colliding with other custom control codes from
other products. To avoid this latter problem, creating a control device
to send the custom control codes at will avert any potential collision.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
One thing to be aware of is that sending a file handle to the control object requires some additional work or it will break the layering. The problem is that if you reference the FILE_OBJECT the handle refers to there is no guarantee that that FILE_OBJECT doesn’t belong to a filter above yours (shadow file object filters do this for example) and if you use it to issue IO you’ll find out that it either doesn’t work or it will crash the system.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Thursday, July 30, 2009 10:02
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Custom FSCTL Question
xxxxx@yahoo.com wrote:
[quote] Does this mean (a) that you want to send FSCTLs on a file
handle (something like…‘secure delete *this* file’ or ‘encrypt
*this* file’)… [/quote]
a)
A control object is no different from the communication port. I already use that. In this case I want to take actions based on an actual file open that was already done on the caller. (Like FSCTL_GET_RETRIEVAL_POINTERS for example).
I suppose I could have the caller send the file handle to the control object who could do access checks, etc. but why bother? I would rather let the IO manager do all of this for me…
For file specific requests using already defines control codes you should keep it as you have it. Your original query though had to do with custom control codes colliding with other custom control codes from other products. To avoid this latter problem, creating a control device to send the custom control codes at will avert any potential collision.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) 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
Per Alex’s point, this is exactly why I would like to go through the entire stack. Per Pete’s point, this thread is getting confusing. I *am* defining custom codes. I just want them to go through the entire stack. But I realize that there may be no good way to do this…
>One thing to be aware of is that sending a file handle to the control
object requires some additional work or it will break the layering
Does that mean that we can make a case to have FSCTL_MOVE_FILE changed? 
That pesky handle stuffed in there caused us some grief.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Alexandru Carp” wrote in message
news:xxxxx@ntfsd…
One thing to be aware of is that sending a file handle to the control object
requires some additional work or it will break the layering. The problem is
that if you reference the FILE_OBJECT the handle refers to there is no
guarantee that that FILE_OBJECT doesn’t belong to a filter above yours
(shadow file object filters do this for example) and if you use it to issue
IO you’ll find out that it either doesn’t work or it will crash the system.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Thursday, July 30, 2009 10:02
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Custom FSCTL Question
xxxxx@yahoo.com wrote:
>
>
> a)
>
> A control object is no different from the communication port. I already
> use that. In this case I want to take actions based on an actual file open
> that was already done on the caller. (Like FSCTL_GET_RETRIEVAL_POINTERS
> for example).
>
> I suppose I could have the caller send the file handle to the control
> object who could do access checks, etc. but why bother? I would rather let
> the IO manager do all of this for me…
>
For file specific requests using already defines control codes you should
keep it as you have it. Your original query though had to do with custom
control codes colliding with other custom control codes from other products.
To avoid this latter problem, creating a control device to send the custom
control codes at will avert any potential collision.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
—
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars (including our new fs
mini-filter seminar) 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
Here is what I would do:
- Keep your design of sending the FSCTL on the file
- Define a GUID parameter at the start of your input buffer
- Generate a GUID one time - say GUID1 - for use as a constant identifier for your filter
- Your app will always issue the FSCTL with GUID1 as the parameter
- Your driver will always check the GUID parameter in the input buffer of the FSCTL for GUID1 before claiming it as
your own
This does not protect you against someone else not being as defensive as I propose above. So a filter about you may just
claim this FSCTL as his if the FSCTL code matches.
Also there is no guarantee that GUID1 would not be identical to some data that may be sent down by another app-filter
combination that is not using this defensive mechanism. So the potential for conflict still exists, even with a filter
below you.
But it is a step in the right direction. If you ask me, this mechanism for conflict resolution between overlapping use
of FSCTLs should have been defined in the system from the start.
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
xxxxx@yahoo.com wrote:
Per Alex’s point, this is exactly why I would like to go through the entire stack. Per Pete’s point, this thread is getting confusing. I *am* defining custom codes. I just want them to go through the entire stack. But I realize that there may be no good way to do this…
1 Like
Here is what I would do:
- Keep your design of sending the FSCTL on the file
- Define a GUID parameter at the start of your input buffer
- Generate a GUID one time - say GUID1 - for use as a constant identifier for your filter
- Your app will always issue the FSCTL with GUID1 as the parameter
- Your driver will always check the GUID parameter in the input buffer of the FSCTL for GUID1 before claiming it as
your own
This does not protect you against someone else not being as defensive as I propose above. So a filter about you may just
claim this FSCTL as his if the FSCTL code matches.
Also there is no guarantee that GUID1 would not be identical to some data that may be sent down by another app-filter
combination that is not using this defensive mechanism. So the potential for conflict still exists, even with a filter
below you.
But it is a step in the right direction. If you ask me, this mechanism for conflict resolution between overlapping use
of FSCTLs should have been defined in the system from the start.
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
xxxxx@yahoo.com wrote:
Per Alex’s point, this is exactly why I would like to go through the entire stack. Per Pete’s point, this thread is getting confusing. I *am* defining custom codes. I just want them to go through the entire stack. But I realize that there may be no good way to do this…
Sarosh,
I am already doing exactly what you propose. I guess I will keep it for now and see who breaks me at PlugFest!
Thanks,
Matt