Hi, all
Some time ago, I’ve read here that pointers shouldn’t be passed
to in/out buffers for IOCTL requests. I would like to know why exactly
I should not do it.
I want to pass OBJECT_ATTRIBUTES structure to an IOCTL
for my driver (using METHOD_NEITHER) this approach:
typedef struct _MY_IOCTL_IN_DATA
{
OBJECT_ATTRIBUTES ObjAttr; // ObjectName points to the next
member
UNICODE_STRING ObjName; // Buffer points to the next member
WCHAR Buffer[1]; // Variable length, as
necessary
} MY_IOCTL_IN_DATA;
In this structure, there are two pointers (I’ll never use
ObjAttr.Security Descriptor and ObjAttr.SecurityQualityOfService).
The first pointer is the ObjAttr.Object name, pointing to
the “ObjName” struct member. The second is ObjName.Buffer,
pointing to the “Buffer” structure member. So all pointers are
self-relative and placed in one buffer.
Is something wrong on this approach (also when considering
future 64-bit versions or changes) ?
L.
There are a couple of reasons to avoid this, first since pointer size is
different from 32-bit to 64-bit you have problems as you change
architectures. Since my local computer store had an Athalon 64 system for
$500 recently, I would say that 64 bit truly cannot be ignored. The second
big problem is you have to validate the data yourself, and most people get
it wrong. This is also why METHOD_NEITHER is discouraged, since you have
the same validation problem.
Pass in the Attributes field of ObjAttr, the length of the string and buffer
as the last element, this is a better safer approach, and get rid of the
METHOD_NEITHER.
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, June 22, 2005 5:41 AM
Subject: [ntfsd] Passing pointers to IOCTL input buffers
> Hi, all
>
> Some time ago, I’ve read here that pointers shouldn’t be passed
> to in/out buffers for IOCTL requests. I would like to know why exactly
> I should not do it.
>
> I want to pass OBJECT_ATTRIBUTES structure to an IOCTL
> for my driver (using METHOD_NEITHER) this approach:
>
> typedef struct _MY_IOCTL_IN_DATA
> {
> OBJECT_ATTRIBUTES ObjAttr; // ObjectName points to the next
> member
> UNICODE_STRING ObjName; // Buffer points to the next member
> WCHAR Buffer[1]; // Variable length, as
> necessary
> } MY_IOCTL_IN_DATA;
>
> In this structure, there are two pointers (I’ll never use
> ObjAttr.Security Descriptor and ObjAttr.SecurityQualityOfService).
>
> The first pointer is the ObjAttr.Object name, pointing to
> the “ObjName” struct member. The second is ObjName.Buffer,
> pointing to the “Buffer” structure member. So all pointers are
> self-relative and placed in one buffer.
>
> Is something wrong on this approach (also when considering
> future 64-bit versions or changes) ?
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> There are a couple of reasons to avoid this, first since pointer size is
different from 32-bit to 64-bit you have problems as you change
architectures.
But porting to 64-bit will require to recompile both the driver and the user
mode component sending the IOCTL, so I don’t understand why this
should be a problem.
Anyway, I will replace the pointers with relative offsets on the
usermode side, and restore them back in the driver. This will work
regardless of if I use METHOD_NEITHER or not.
Thank you for the answer.
L.
No, you can have a 32 bit application on x64 and then you have deal with the
problems. Also, why create the problems of using METHOD_NEITHER if you do
not have to.
I fairly often get requests to improve or fix drivers that other have
written. I have a checklist of things I look at on the first pass to get an
idea of how bad the driver will be. Two of the items that go in the bad
side are pointers in IOCTL’s and METHOD_NEITHER!
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, June 22, 2005 8:20 AM
Subject: Re: [ntfsd] Passing pointers to IOCTL input buffers
>> There are a couple of reasons to avoid this, first since pointer size is
>> different from 32-bit to 64-bit you have problems as you change
>> architectures.
>
> But porting to 64-bit will require to recompile both the driver and the
> user
> mode component sending the IOCTL, so I don’t understand why this
> should be a problem.
>
> Anyway, I will replace the pointers with relative offsets on the
> usermode side, and restore them back in the driver. This will work
> regardless of if I use METHOD_NEITHER or not.
>
> Thank you for the answer.
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@acm.org
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
It will be hard to validate such pointers, especially for METHOD_BUFFERED
IOCTL.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, June 22, 2005 1:41 PM
Subject: [ntfsd] Passing pointers to IOCTL input buffers
> Hi, all
>
> Some time ago, I’ve read here that pointers shouldn’t be passed
> to in/out buffers for IOCTL requests. I would like to know why exactly
> I should not do it.
>
> I want to pass OBJECT_ATTRIBUTES structure to an IOCTL
> for my driver (using METHOD_NEITHER) this approach:
>
> typedef struct _MY_IOCTL_IN_DATA
> {
> OBJECT_ATTRIBUTES ObjAttr; // ObjectName points to the next
> member
> UNICODE_STRING ObjName; // Buffer points to the next member
> WCHAR Buffer[1]; // Variable length, as
> necessary
> } MY_IOCTL_IN_DATA;
>
> In this structure, there are two pointers (I’ll never use
> ObjAttr.Security Descriptor and ObjAttr.SecurityQualityOfService).
>
> The first pointer is the ObjAttr.Object name, pointing to
> the “ObjName” struct member. The second is ObjName.Buffer,
> pointing to the “Buffer” structure member. So all pointers are
> self-relative and placed in one buffer.
>
> Is something wrong on this approach (also when considering
> future 64-bit versions or changes) ?
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> I fairly often get requests to improve or fix drivers that other have
written. I have a checklist of things I look at on the first pass to get
an idea of how bad the driver will be. Two of the items that go in the
bad side are pointers in IOCTL’s and METHOD_NEITHER!
Well, thank you again for the advice. Better to do it
recommended way 
L.
I agree that it is best to not pass pointers or handles in FSCTLS; they
both have the issue of being a different size between 32bit and 64bit
systems.
Since there are times when you might have to do this for a good reason
(compatibility with an older version of a product being one); the
minispy sample in the Srv03 SP1 IFSKit shows you how to detect this
situation when using filter manager messaging APIs. The same principles
apply to an FSCTL. Look for the api IoIs32bitProcess. You should read
the documentation for this API as well as FltIs32bitProcess.
Neal Christiansen
Microsoft File System Filter Group Lead
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 Ladislav Zezula
Sent: Wednesday, June 22, 2005 5:59 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Passing pointers to IOCTL input buffers
I fairly often get requests to improve or fix drivers that other have
written. I have a checklist of things I look at on the first pass to
get
an idea of how bad the driver will be. Two of the items that go in
the
bad side are pointers in IOCTL’s and METHOD_NEITHER!
Well, thank you again for the advice. Better to do it
recommended way
L.
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thank you. I already have implemented it by
converting pointers to offsets and converting them back
again in the driver. I don’t want to mix 32-bit
user mode components with 64-bit driver, so
different pointer size is not an issue.
L.
----- Original Message -----
From: “Neal Christiansen”
To: “Windows File Systems Devs Interest List”
Sent: Friday, July 01, 2005 8:10 AM
Subject: RE: [ntfsd] Passing pointers to IOCTL input buffers
I agree that it is best to not pass pointers or handles in FSCTLS; they
both have the issue of being a different size between 32bit and 64bit
systems.
Since there are times when you might have to do this for a good reason
(compatibility with an older version of a product being one); the
minispy sample in the Srv03 SP1 IFSKit shows you how to detect this
situation when using filter manager messaging APIs. The same principles
apply to an FSCTL. Look for the api IoIs32bitProcess. You should read
the documentation for this API as well as FltIs32bitProcess.
Neal Christiansen
Microsoft File System Filter Group Lead
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 Ladislav Zezula
Sent: Wednesday, June 22, 2005 5:59 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Passing pointers to IOCTL input buffers
> I fairly often get requests to improve or fix drivers that other have
> written. I have a checklist of things I look at on the first pass to
get
> an idea of how bad the driver will be. Two of the items that go in
the
> bad side are pointers in IOCTL’s and METHOD_NEITHER!
Well, thank you again for the advice. Better to do it
recommended way
L.
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.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