In an IOCTL if I am copying more than 1 page worth of data from user->kernel space and also the other way around… am I safe with using METHOD_OUT_DIRECT?
I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside my IOCTL handler… this is with > 1 page worth of data being transferred in… Would someone know why that I am getting that?
Thanks
-Johnny
Join the world’s largest e-mail service with MSN Hotmail. Click Here
using METHOD_*_DIRECT for your ioctls opens your driver up to all sorts
of attacks from user-mode (malicious applications can modify data values
in the buffer after you’ve validated them. Poorly written apps could
reuse the pages for something else very easily). If it’s not
performance critical then it’s probably not worth the work needed to
secure it properly.
no clue on the second point unless the caller to DeviceIoControl handed
in bad parameters. But it sounds like you’re ruling that out.
-p
-----Original Message-----
From: Johnny D [mailto:xxxxx@hotmail.com]
Sent: Tuesday, May 14, 2002 2:54 PM
To: NT Developers Interest List
Subject: [ntdev] METHOD_DIRECT - Please help!
In an IOCTL if I am copying more than 1 page worth of data from
user->kernel space and also the other way around… am I safe with using
METHOD_OUT_DIRECT?
I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside
my IOCTL handler… this is with > 1 page worth of data being transferred
in… Would someone know why that I am getting that?
Thanks
-Johnny
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
Peter, Thanks for responding. The main reason I am using this is because in Walter Oney’s book, I read that if you are xferring >1 pg worth of data, one shouldnt use METHOD_BUFFERED. I believe that is for performance reasons, but are there any other reasons as to why this might be a problem?
If one is using METHOD_OUT_DIRECT is Irp->AssociatedIrp.SystemBuffer supposed to be pointing to valid data from which I can read stuff into?.
Regards
-Johnny
From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: METHOD_DIRECT - Please help!
>Date: Tue, 14 May 2002 15:16:58 -0700
>
>using METHOD_*_DIRECT for your ioctls opens your driver up to all sorts
>of attacks from user-mode (malicious applications can modify data values
>in the buffer after you’ve validated them. Poorly written apps could
>reuse the pages for something else very easily). If it’s not
>performance critical then it’s probably not worth the work needed to
>secure it properly.
>
>no clue on the second point unless the caller to DeviceIoControl handed
>in bad parameters. But it sounds like you’re ruling that out.
>
>-p
>
>-----Original Message-----
>From: Johnny D [mailto:xxxxx@hotmail.com]
>Sent: Tuesday, May 14, 2002 2:54 PM
>To: NT Developers Interest List
>Subject: [ntdev] METHOD_DIRECT - Please help!
>
>
>In an IOCTL if I am copying more than 1 page worth of data from
>user->kernel space and also the other way around… am I safe with using
>METHOD_OUT_DIRECT?
>I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside
>my IOCTL handler… this is with > 1 page worth of data being transferred
>in… Would someone know why that I am getting that?
>
>Thanks
>-Johnny
>
>
MSN Photos is the easiest way to share and print your photos: Click Here
Jamey Hanrahan in a seminar I took describes it best —
METHOD_*_DIRECT redefines the use of the input/output buffers. Input becomes a pointer to a control buffer, where as output becomes the data buffer. On entry to your drivers Dispatch control method IRP->Associated buffer points to the “control” buffer where as IRP->MdlAddress points the MDL that has been created for the data buffer.
As to why “control” might be NULL, I would hazard a guess that the Input pointer was null and or the size was 0.
–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“Johnny D” wrote in message news:xxxxx@ntdev…
In an IOCTL if I am copying more than 1 page worth of data from user->kernel space and also the other way around… am I safe with using METHOD_OUT_DIRECT?
I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside my IOCTL handler… this is with > 1 page worth of data being transferred in… Would someone know why that I am getting that?
Thanks
-Johnny
------------------------------------------------------------------------------
Join the world’s largest e-mail service with MSN Hotmail. Click Here
Gary, thanks for the information. I am seeing this problem even with METHOD_BUFFERED … And this is after making sure that some junk input is *not* being passed into DeviceIoControl. I am re-posting my recent mail for quick reference
Maybe I should qualify my question some more. What I noticed is that Irp->AssociatedIrp.SystemBuffer was NULL when i tried to pass in > 1pg worth of data into the kernel even with METHOD_BUFFERED. Not sure as to why that is the case, so if someone has some idea on that, please let me know. It does not fail every time. I make the IOCTL call every second, with the same input parameter, and it usually fails in the 2nd call. 1st one goes thru fine.
Specifically, if I am going to passing in AND out more than 1 page worth of data between the app and the driver, what method should I be using?. Do let me know of the caveats, if any, as well, like Peter did.
Thanks
-Johnny
From: “Gary G. Little”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: METHOD_DIRECT - Please help!
>Date: Wed, 15 May 2002 09:31:23 -0700
>
>Jamey Hanrahan in a seminar I took describes it best —
>
>METHOD_*_DIRECT redefines the use of the input/output buffers. Input becomes a pointer to a control buffer, where as output becomes the data buffer. On entry to your drivers Dispatch control method IRP->Associated buffer points to the “control” buffer where as IRP->MdlAddress points the MDL that has been created for the data buffer.
>
>As to why “control” might be NULL, I would hazard a guess that the Input pointer was null and or the size was 0.
>
>–
>Gary G. Little
>xxxxx@broadstor.com
>xxxxx@inland.net
> “Johnny D” wrote in message news:xxxxx@ntdev…
> In an IOCTL if I am copying more than 1 page worth of data from user->kernel space and also the other way around… am I safe with using METHOD_OUT_DIRECT?
>
> I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside my IOCTL handler… this is with > 1 page worth of data being transferred in… Would someone know why that I am getting that?
>
>
> Thanks
> -Johnny
>
>
>------------------------------------------------------------------------------
> Join the world’s largest e-mail service with MSN Hotmail. Click Here
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
MSN Photos is the easiest way to share and print your photos: Click Here
If you are processing these buffers in the kernel in the same context
that you receive them in, then use METHOD_NEITHER. Using this, you get
the addresses directly. You can then lock them and pass them to a worker
thread, if needed.
Pete
Peter Scott
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Johnny D
Sent: Wednesday, May 15, 2002 1:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Gary, thanks for the information. I am seeing this problem even with
METHOD_BUFFERED … And this is after making sure that some junk input
is *not* being passed into DeviceIoControl. I am re-posting my recent
mail for quick reference
Maybe I should qualify my question some more. What I noticed is that
Irp->AssociatedIrp.SystemBuffer was NULL when i tried to pass in > 1pg
worth of data into the kernel even with METHOD_BUFFERED. Not sure as to
why that is the case, so if someone has some idea on that, please let me
know. It does not fail every time. I make the IOCTL call every second,
with the same input parameter, and it usually fails in the 2nd call. 1st
one goes thru fine.
Specifically, if I am going to passing in AND out more than 1 page worth
of data between the app and the driver, what method should I be using?.
Do let me know of the caveats, if any, as well, like Peter did.
Thanks
-Johnny
From: “Gary G. Little”
Reply-To: “NT Developers Interest List”
To: “NT Developers Interest List”
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Date: Wed, 15 May 2002 09:31:23 -0700
Jamey Hanrahan in a seminar I took describes it best —
METHOD_*_DIRECT redefines the use of the input/output buffers. Input
becomes a pointer to a control buffer, where as output becomes the data
buffer. On entry to your drivers Dispatch control method IRP->Associated
buffer points to the “control” buffer where as IRP->MdlAddress points
the MDL that has been created for the data buffer.
As to why “control” might be NULL, I would hazard a guess that the
Input pointer was null and or the size was 0.
–
Gary G. Little
“Johnny D” wrote in message news:xxxxx@ntdev…
In an IOCTL if I am copying more than 1 page worth of data from
user->kernel space and also the other way around… am I safe with using
METHOD_OUT_DIRECT?
I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when
inside my IOCTL handler… this is with > 1 page worth of data being
transferred in… Would someone know why that I am getting that?
Thanks
-Johnny
Join the world’s largest e-mail service with MSN Hotmail. Click Here
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to %%email.unsub%%
MSN Photos is the easiest way to share and print your photos: Click Here
http:
—
You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
To unsubscribe send a blank email to %%email.unsub%%</http:>
are you calling from user-mode or kernel mode? What API are you using
to build/send the device control request?
if you’re sending buffered ioctls from user-mode you should never see
the SystemBuffer == NULL unless you passed in no data buffer (or a zero
input & output length) to the call to DeviceIoControl.
-p
-----Original Message-----
From: Johnny D [mailto:xxxxx@hotmail.com]
Sent: Wednesday, May 15, 2002 12:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Maybe I should qualify my question some more. What I noticed is that
Irp->AssociatedIrp.SystemBuffer was NULL when i tried to pass in > 1pg
worth of data into the kernel even with METHOD_BUFFERED. Not sure as to
why that is the case, so if someone has some idea on that, please let me
know. It does not fail every time. I make the IOCTL call every second,
with the same input parameter, and it usually fails in the 2nd call. 1st
one goes thru fine.
Specifically, if I am going to passing in AND out more than 1 page worth
of data between the app and the driver, what method should I be using?.
Do let me know of the caveats, if any, as well, like Peter did.
Thanks
-Johnny
From: “Gary G. Little”
Reply-To: “NT Developers Interest List”
To: “NT Developers Interest List”
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Date: Wed, 15 May 2002 09:31:23 -0700Jamey Hanrahan in a seminar I took describes it best —
METHOD_*_DIRECT redefines the use of the input/output buffers. Input
becomes a pointer to a control buffer, where as output becomes the data
buffer. On entry to your drivers Dispatch control method IRP->Associated
buffer points to the “control” buffer where as IRP->MdlAddress points
the MDL that has been created for the data buffer.As to why “control” might be NULL, I would hazard a guess that the
Input pointer was null and or the size was 0.–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“Johnny D” wrote in message news:xxxxx@ntdev…
In an IOCTL if I am copying more than 1 page worth of data from
user->kernel space and also the other way around… am I safe with using
METHOD_OUT_DIRECT?I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when
inside my IOCTL handler… this is with > 1 page worth of data being
transferred in… Would someone know why that I am getting that?Thanks
-Johnny
Join the world’s largest e-mail service with MSN Hotmail. Click Here
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
this requires even more tiptoeing around than METHOD_DIRECT to ensure
you don’t create a security hole. with method direct you know you’ve
got a data buffer to use. With METHOD_NEITHER you only get a pointer to
a data buffer. That pointer could be a kernel-mode address, a user-mode
address, NULL, an invalid address, etc…
-p
-----Original Message-----
From: Peter Scott [mailto:xxxxx@KernelDrivers.com]
Sent: Wednesday, May 15, 2002 12:40 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
If you are processing these buffers in the kernel in the same context
that you receive them in, then use METHOD_NEITHER. Using this, you get
the addresses directly. You can then lock them and pass them to a worker
thread, if needed.
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Johnny D
Sent: Wednesday, May 15, 2002 1:15 PM
To: NT Developers Interest List
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Maybe I should qualify my question some more. What I noticed is that
Irp->AssociatedIrp.SystemBuffer was NULL when i tried to pass in > 1pg
worth of data into the kernel even with METHOD_BUFFERED. Not sure as to
why that is the case, so if someone has some idea on that, please let me
know. It does not fail every time. I make the IOCTL call every second,
with the same input parameter, and it usually fails in the 2nd call. 1st
one goes thru fine.
Specifically, if I am going to passing in AND out more than 1 page worth
of data between the app and the driver, what method should I be using?.
Do let me know of the caveats, if any, as well, like Peter did.
Thanks
-Johnny
From: “Gary G. Little”
Reply-To: “NT Developers Interest List”
To: “NT Developers Interest List”
Subject: [ntdev] Re: METHOD_DIRECT - Please help!
Date: Wed, 15 May 2002 09:31:23 -0700Jamey Hanrahan in a seminar I took describes it best —
METHOD_*_DIRECT redefines the use of the input/output buffers. Input
becomes a pointer to a control buffer, where as output becomes the data
buffer. On entry to your drivers Dispatch control method IRP->Associated
buffer points to the “control” buffer where as IRP->MdlAddress points
the MDL that has been created for the data buffer.As to why “control” might be NULL, I would hazard a guess that the
Input pointer was null and or the size was 0.–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“Johnny D” wrote in message news:xxxxx@ntdev…
In an IOCTL if I am copying more than 1 page worth of data from
user->kernel space and also the other way around… am I safe with using
METHOD_OUT_DIRECT?I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when
inside my IOCTL handler… this is with > 1 page worth of data being
transferred in… Would someone know why that I am getting that?Thanks
-Johnny
Join the world’s largest e-mail service with MSN Hotmail. Click Here
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
In the second call the input size does go to 0, although the pointer is pointing to valid data. Not sure why, but I will continue to investigate. Thanks to all who helped me in this issue.
Regards
-Johnny
From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: METHOD_DIRECT - Please help!
>Date: Wed, 15 May 2002 12:48:44 -0700
>
>are you calling from user-mode or kernel mode? What API are you using
>to build/send the device control request?
>
>if you’re sending buffered ioctls from user-mode you should never see
>the SystemBuffer == NULL unless you passed in no data buffer (or a zero
>input & output length) to the call to DeviceIoControl.
>
>-p
>-----Original Message-----
>From: Johnny D [mailto:xxxxx@hotmail.com]
>Sent: Wednesday, May 15, 2002 12:15 PM
>To: NT Developers Interest List
>Subject: [ntdev] Re: METHOD_DIRECT - Please help!
>
>
>Gary, thanks for the information. I am seeing this problem even with
>METHOD_BUFFERED … And this is after making sure that some junk input
>is not being passed into DeviceIoControl. I am re-posting my recent
>mail for quick reference
>---------
>Maybe I should qualify my question some more. What I noticed is that
>Irp->AssociatedIrp.SystemBuffer was NULL when i tried to pass in > 1pg
>worth of data into the kernel even with METHOD_BUFFERED. Not sure as to
>why that is the case, so if someone has some idea on that, please let me
>know. It does not fail every time. I make the IOCTL call every second,
>with the same input parameter, and it usually fails in the 2nd call. 1st
>one goes thru fine.
>Specifically, if I am going to passing in AND out more than 1 page worth
>of data between the app and the driver, what method should I be using?.
>Do let me know of the caveats, if any, as well, like Peter did.
>
>---------
>
>
>Thanks
>-Johnny
> >From: “Gary G. Little”
> >Reply-To: “NT Developers Interest List”
> >To: “NT Developers Interest List”
> >Subject: [ntdev] Re: METHOD_DIRECT - Please help!
> >Date: Wed, 15 May 2002 09:31:23 -0700
> >
> >Jamey Hanrahan in a seminar I took describes it best —
> >
> >METHOD_*_DIRECT redefines the use of the input/output buffers. Input
>becomes a pointer to a control buffer, where as output becomes the data
>buffer. On entry to your drivers Dispatch control method IRP->Associated
>buffer points to the “control” buffer where as IRP->MdlAddress points
>the MDL that has been created for the data buffer.
> >
> >As to why “control” might be NULL, I would hazard a guess that the
>Input pointer was null and or the size was 0.
> >
> >–
> >Gary G. Little
> >xxxxx@broadstor.com
> >xxxxx@inland.net
> > “Johnny D” wrote in message news:xxxxx@ntdev…
> > In an IOCTL if I am copying more than 1 page worth of data from
>user->kernel space and also the other way around… am I safe with using
>METHOD_OUT_DIRECT?
> >
> > I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when
>inside my IOCTL handler… this is with > 1 page worth of data being
>transferred in… Would someone know why that I am getting that?
> >
> >
> > Thanks
> > -Johnny
> >
> >
> >-----------------------------------------------------------------------
>-------
> > Join the world’s largest e-mail service with MSN Hotmail. Click Here
> >
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>MSN Photos is the easiest way to share and print your photos: Click Here
>—
>You are currently subscribed to ntdev as: xxxxx@microsoft.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
Chat with friends online, try MSN Messenger: Click Here
Both METHOD_xxx_DIRECT pass InputBuffer as AssociatedIrp.SystemBuffer and OutputBuffer as MdlAddress.
For METHOD_IN_DIRECT, MDL at MdlAddress must be filled by the driver. This is like read() to OutputBuffer with additional parameters (InputBuffer).
For METHOD_OUT_DIRECT, MDL at MdlAddress is filled by the app and can be accessed but not updated by the driver. This is like write() from OutputBuffer with additional parameters (InputBuffer). Yes, 2 input buffers, one small for some parameters, one large for data payload.
Max
----- Original Message -----
From: Johnny D
To: NT Developers Interest List
Sent: Wednesday, May 15, 2002 3:00 AM
Subject: [ntdev] RE: METHOD_DIRECT - Please help!
Peter, Thanks for responding. The main reason I am using this is because in Walter Oney’s book, I read that if you are xferring >1 pg worth of data, one shouldnt use METHOD_BUFFERED. I believe that is for performance reasons, but are there any other reasons as to why this might be a problem?
If one is using METHOD_OUT_DIRECT is Irp->AssociatedIrp.SystemBuffer supposed to be pointing to valid data from which I can read stuff into?.
Regards
-Johnny
From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: METHOD_DIRECT - Please help!
>Date: Tue, 14 May 2002 15:16:58 -0700
>
>using METHOD_*_DIRECT for your ioctls opens your driver up to all sorts
>of attacks from user-mode (malicious applications can modify data values
>in the buffer after you’ve validated them. Poorly written apps could
>reuse the pages for something else very easily). If it’s not
>performance critical then it’s probably not worth the work needed to
>secure it properly.
>
>no clue on the second point unless the caller to DeviceIoControl handed
>in bad parameters. But it sounds like you’re ruling that out.
>
>-p
>
>-----Original Message-----
>From: Johnny D [mailto:xxxxx@hotmail.com]
>Sent: Tuesday, May 14, 2002 2:54 PM
>To: NT Developers Interest List
>Subject: [ntdev] METHOD_DIRECT - Please help!
>
>
>In an IOCTL if I am copying more than 1 page worth of data from
>user->kernel space and also the other way around… am I safe with using
>METHOD_OUT_DIRECT?
>I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside
>my IOCTL handler… this is with > 1 page worth of data being transferred
>in… Would someone know why that I am getting that?
>
>Thanks
>-Johnny
>
>
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
Important to note, if you are using METHOD_XXX_DIRECT IOCTLs, your MDL buffer pages are only probed one way. So, if you need to read AND write data to these pages, you need to probe the unprobed direction yourself. Now, that said, for x86 I believe the page permissions are set for read and write anyway, but this could change, (unlikely), or it may not be true on a non-x86 platform?? This isn’t documented anywhere that I am aware of.
Intersting to note also, that for an IOCTL the input and output buffers are setup such that for the input buffer the data path is app to driver, assuming an app is making a DeviceIoControl call here. But, for METHOD_IN_DIRECT IOCTLs the data path for the MDL data is driver to app. So, *IN* here means different things. If you look at it from the driver’s perspective, *IN* is always towards the driver, so the input buffer is coming in from above to the driver, and METHOD_IN_DIRECT is indicating that data is being DMA’d into the driver as well. But this is heinously counter intuitive, especially for the newbie. What is really amazing about this is that someone setup this convoluted scheme and then decided not to document it clearly anywhere 
–
Bill McKenzie
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
Both METHOD_xxx_DIRECT pass InputBuffer as AssociatedIrp.SystemBuffer and OutputBuffer as MdlAddress.
For METHOD_IN_DIRECT, MDL at MdlAddress must be filled by the driver. This is like read() to OutputBuffer with additional parameters (InputBuffer).
For METHOD_OUT_DIRECT, MDL at MdlAddress is filled by the app and can be accessed but not updated by the driver. This is like write() from OutputBuffer with additional parameters (InputBuffer). Yes, 2 input buffers, one small for some parameters, one large for data payload.
Max
----- Original Message -----
From: Johnny D
To: NT Developers Interest List
Sent: Wednesday, May 15, 2002 3:00 AM
Subject: [ntdev] RE: METHOD_DIRECT - Please help!
Peter, Thanks for responding. The main reason I am using this is because in Walter Oney’s book, I read that if you are xferring >1 pg worth of data, one shouldnt use METHOD_BUFFERED. I believe that is for performance reasons, but are there any other reasons as to why this might be a problem?
If one is using METHOD_OUT_DIRECT is Irp->AssociatedIrp.SystemBuffer supposed to be pointing to valid data from which I can read stuff into?.
Regards
-Johnny
>From: “Peter Wieland”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: METHOD_DIRECT - Please help!
>Date: Tue, 14 May 2002 15:16:58 -0700
>
>using METHOD_*_DIRECT for your ioctls opens your driver up to all sorts
>of attacks from user-mode (malicious applications can modify data values
>in the buffer after you’ve validated them. Poorly written apps could
>reuse the pages for something else very easily). If it’s not
>performance critical then it’s probably not worth the work needed to
>secure it properly.
>
>no clue on the second point unless the caller to DeviceIoControl handed
>in bad parameters. But it sounds like you’re ruling that out.
>
>-p
>
>-----Original Message-----
>From: Johnny D [mailto:xxxxx@hotmail.com]
>Sent: Tuesday, May 14, 2002 2:54 PM
>To: NT Developers Interest List
>Subject: [ntdev] METHOD_DIRECT - Please help!
>
>
>In an IOCTL if I am copying more than 1 page worth of data from
>user->kernel space and also the other way around… am I safe with using
>METHOD_OUT_DIRECT?
>I once saw that the Irp->AssociatedIrp.SystemBuffer was NULL when inside
>my IOCTL handler… this is with > 1 page worth of data being transferred
>in… Would someone know why that I am getting that?
>
>Thanks
>-Johnny
>
>
----------------------------------------------------------------------------
MSN Photos is the easiest way to share and print your photos: Click Here
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%