Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

when to use EvtIoInCallerContext

Emil_HasEmil_Has Posts: 56
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

Comments

  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@lists.osr.com>
    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://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • Emil_HasEmil_Has Posts: 56
    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
  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@lists.osr.com>
    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://www.osronline.com/showlists.cfm?list=ntdev>;

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
    drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at
    <http://www.osronline.com/page.cfm?name=ListServer>;
  • Tim_RobertsTim_Roberts Posts: 12,622
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!