The use of user-mode pointers embedded in structures has been a
historically difficult thing to get correct, resulting in very difficult
to debug crashes, security holes, and/or random memory corruption. The
main problem is that you are not allowing the NT IO manager to make that
buffer “safe” for use within the kernel. That buffer can be
deallocated/reallocated to a different process while the irp is in
process, so special care must be taken in any/all validation paths.
Generally speaking, you want to avoid this in all cases by using
METHOD_BUFFERED without any internal pointers.
There are, however, a very few exceptions to this rule. If you are
doing performance-critical code (where performance analysis tools say
double-buffering the memory is a bottleneck), the compromise option is
to use METHOD_BUFFERED for the IOCTL parameters, with only one pointer
to the buffer provided within that structure. This is typically only
done if you need to support READ/WRITE of more than a page at a time on
hard disks, networking devices, etc.
However, this has *still* been a historically difficult area to get
correct. One reason is that you must ensure that you are in the
original caller’s context while processing the irp – not all stacks
guarantee this. Also, you cannot do any validation of the user buffer
until you make a locked copy of it – else the user can change it’s
values after the validation has occurred. There are lots of other
“gotchas”, which I don’t know about as I have avoided this type of
design.
IOCTL_SCSI_PASS_THROUGH_DIRECT uses this method to allow better
performance for pass-through requests. However, this then requires
additional work by the caller to ensure their memory buffers are aligned
properly for the given device(*), which requires additional work in the
client also. The MSFT storage port drivers have consolidated their
handling of this IOCTL into a single library because many
implementations had previously missed an edge case or two. The IO
manager really does us a favor by buffering IO!
I could go on and on about the difficulty of implementing this
correctly, especially if you’re doing it the first time around. I am
reasonably sure that anything you are doing can be done using
METHOD_BUFFERED without any additional pointers; sometimes it requires
creative use of the input/output buffers, but I encourage you (for both
our customers experience) to avoid using embedded pointers whenever
possible.
Hth,
.
(*) Storage provides this info via IOCTL_STORAGE_QUERY_PROPERTY,
AdapterDescriptor.
-----Original Message-----
From: xxxxx@sonydadc.com [mailto:xxxxx@sonydadc.com]
Sent: Monday, December 22, 2003 12:46 AM
Subject: RE: setting Irp->MdlAddress manually
Mark,
Is it a questionable design to embedd a (usermode) buffer within another
buffer?
Or is it just questionable to assume it’s a usermode buffer?
Best Regards
Michael
“Roddy, Mark”
Sent by: xxxxx@lists.osr.com
19.12.2003 19:14
Please respond to
“Windows System Software Devs Interest List”
To
“Windows System Software Devs Interest List”
cc
Subject
[ntdev] RE: setting Irp->MdlAddress manually
I think he means that the contents of the system buffer contain an
embedded
pointer which he just “knows” is a user mode address. This is of course
wrong design on many levels. I actually don’t know and don’t care if
manually whacking the Irp.MdlAddress will result in the current version
of
the IO Manager cleaning up his mess for him, this approach is also wrong
design on many levels. The OP should consider correct design instead and
not
try to be really tricky and lazy.
=====================
Mark Roddy
________________________________
From: Calvin Guan [mailto:xxxxx@ati.com]
Sent: Friday, December 19, 2003 12:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: setting Irp->MdlAddress manually
>But the buffer given via AssociatedIrp.SystemBuffer
contains a
pointer to a usermode address.
Just couldn’t imagine how the rest of drivers would
survive if this
is true.
The SystemBuffer is allocated from NPAGE pool and it’s
accessible in
arbitrary context. Are you sure your are receiving the desired IRP?
Calvin Guan, Software Engineer xxxxx@nospam.ati.com
ATI Technologies Inc. Tel: (905) 882-2600 Ext. 8654
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to
ntdev as: xxxxx@ati.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@stratus.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@sonydadc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
