Hi
I’ll appreciate if you can give some examples of cases we should use EvtIoInCallerContext event callback, by registering WdfDeviceInitSetIoInCallerContextCallback.
Is that should be used only for METHOD_NIETHER , in order to ensure the user’s context , validate and lock the user buffer before the usage , or there are more cases ?
what other cases ?
what is the idea behind it ? If on “Neither Buffered” we must intercept the request and lock before the I/O queue , so what the difference with “Direct I/O” where this code will be done anyway ?
thank you
There are more cases, a variant of METHOD_NEITHER is when you pass a pointer
in a structure. There are oddball cases where you want be in the callers
process to do something.
Understand that a common case of METHOD_NEITHER is when you do not want to
pass a buffer, i.e. you have data you want to pass in that can fit in two
pointer sized variable and two ULONG’s, and can be returned in one pointer
sized variable.
DIRECT_IO or even METHOD_BUFFERED is better in most cases where there is a
buffer. There have been multiple threads on this forum on when each
approach is faster.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Sunday, January 07, 2018 9:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] when to use EvtIoInCallerContext
Hi
I’ll appreciate if you can give some examples of cases we should use
EvtIoInCallerContext event callback, by registering
WdfDeviceInitSetIoInCallerContextCallback.
Is that should be used only for METHOD_NIETHER , in order to ensure the
user’s context , validate and lock the user buffer before the usage , or
there are more cases ?
what other cases ?
what is the idea behind it ? If on “Neither Buffered” we must intercept the
request and lock before the I/O queue , so what the difference with “Direct
I/O” where this code will be done anyway ?
thank you
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
Unfortunately, it is impossible to search on osronline anymore.
I read many times the case you described (with two pointer and two ULONG’s ) but I do not understand it.
Let me change a bit my question.
Once I use Direct IOCTL method , The IO manager locks the user pages in
memory and creates an MDL object which describes user pages.
This more efficient than just copy .
What NIETHER method does ? Nothing.
So in driver EvtIoInCallerContext routine, we should WdfRequestRetrieveUnsafeUserInputBuffer and OutputBuffer , then WdfRequestProbeAndLockUserBufferForRead / Write for both buffers .
then we can return request the framework and use the buffer …
Is that means WdfRequestProbeAndLockUserBufferForRead/Write creates MDL ?
If it creates MDL , so what the difference between two approaches ?
Anyway I can’t use the buffer even if it is small or big .
Regards
Well the search function worked fine for me just now. Just go to the
osronline.com, choose ListServer/Forum, then choose “Click Here To Search
The Lists”
What I meant on using METHOD_NEITHER was for example:
In user space:
DeviceIoControl( handle, IOCTL_CODE, P1, U1, P2, U2, R1, NULL);
In kernel space:
Use WdfRequestWdmGetIrp then P1 is
Parameters.DeviceIoControl.Type3InputBuffer, U1 is
Parameters.DeviceIoControl.InputBufferLength, P2 is IRP->UserBuffer, and U2
is Parameters.DeviceIoControl.OutputBufferLength where Paremeters is the
current IO_STACK_LOCATION.
The 4 parameters can be accessed with no processing of the parameters. The
WdfCompleteRequestWithInformation returns the Information parameter as R1.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, January 08, 2018 8:37 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] when to use EvtIoInCallerContext
Unfortunately, it is impossible to search on osronline anymore.
I read many times the case you described (with two pointer and two ULONG’s )
but I do not understand it.
Let me change a bit my question.
Once I use Direct IOCTL method , The IO manager locks the user pages in
memory and creates an MDL object which describes user pages.
This more efficient than just copy .
What NIETHER method does ? Nothing.
So in driver EvtIoInCallerContext routine, we should
WdfRequestRetrieveUnsafeUserInputBuffer and OutputBuffer , then
WdfRequestProbeAndLockUserBufferForRead / Write for both buffers .
then we can return request the framework and use the buffer …
Is that means WdfRequestProbeAndLockUserBufferForRead/Write creates MDL ?
If it creates MDL , so what the difference between two approaches ?
Anyway I can’t use the buffer even if it is small or big .
Regards
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
xxxxx@hotmail.com wrote:
I read many times the case you described (with two pointer and two ULONG’s ) but I do not understand it.
Let me change a bit my question.
Once I use Direct IOCTL method , The IO manager locks the user pages in
memory and creates an MDL object which describes user pages.
This more efficient than just copy .
Well, you need to be specific: with the direct methods, the I/O manager
copies the first buffer, and locks and maps the output buffer in the
DeviceIoControl call. It doesn’t lock anything else. The CONTENTS of
those two buffers are not processed at all. If either of those buffers
should happen to contain user-mode pointers (which is a poor design, but
has certainly been done), then the driver has to take its own steps to
lock down and map those addresses. That can ONLY be done in the
caller’s context.
What NIETHER method does ? Nothing.
So in driver EvtIoInCallerContext routine, we should WdfRequestRetrieveUnsafeUserInputBuffer and OutputBuffer , then WdfRequestProbeAndLockUserBufferForRead / Write for both buffers .
then we can return request the framework and use the buffer …
Correct. It means you have to do what the I/O manager does for you in
the direct cases. It still doesn’t change the processing of the CONTENTS.
Â
Is that means WdfRequestProbeAndLockUserBufferForRead/Write creates MDL ?
Correct.
Â
If it creates MDL , so what the difference between two approaches ?
Trust. The I/O manager code to map-and-lock is well-tested,
well-protected, and covers lots of corner cases that you probably
wouldn’t think of.
There are essentially no good reasons for a user-mode ioctl interface to
use METHOD_NEITHER. The most significant driver model that uses
METHOD_NEITHER ioctls is the Kernel Streaming interface. They do so
because that interface started out being a kernel-to-kernel interface,
and they wanted the flexibility to use the IRP fields in ways that
didn’t meet the guarantees for direct I/O.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.