locked
Calling user mode function from kernel mode RRS feed

  • Question

  • Hi everyone,

    I've been away from kernel mode development for some years, but have to start again for a certain project :).

    I need to write a network driver that modifies packets based on a specific decision that has to be made by the software (modify or not). I would prefer to write these software routines in user mode (as I would have access to the windows API), but then I will need a really fast (!!!) way to call a user mode function from kernel mode.

    In the "old days" this was accomplished by pending (and completing) IOCTLs that were send from user mode (inverted call). Now with Windows 7 / 8 as the main target OS I was wondering if there is a better way to do this nowadays....especially as I do not want to create a lot of overhead when traversing kernel mode / user mode boundaries.

    So basically: What is the best way to "call a user mode function from kernel mode"?

    Best regards,

    Peter

    Friday, April 6, 2012 11:22 AM

Answers

  • Inverted call is still the best way to do this.  I don't know if I would call it a lot of overhead, a couple of years ago on a project we measured the overhead and found that we could get 1.3 million IOCTL calls per second on a dual-core machine.  There has been some improvements on the user side, API's to reduce overhead and thread pools to speed up handling, but the kernel model is still the same.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, April 6, 2012 11:29 AM

All replies

  • Inverted call is still the best way to do this.  I don't know if I would call it a lot of overhead, a couple of years ago on a project we measured the overhead and found that we could get 1.3 million IOCTL calls per second on a dual-core machine.  There has been some improvements on the user side, API's to reduce overhead and thread pools to speed up handling, but the kernel model is still the same.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, April 6, 2012 11:29 AM
  • Thanks a lot for this fast reply!

    I really thought I understood inverted calls, but now I do have some problems in understanding the concepts (after reading the OSR article about it):

    Usually my user mode application will send a user-defined IOCTLs to my driver, which will be pended as long as it takes until a network packet arrives. Now the driver needs to decide whether this packet needs to be modified before it gets passed along - or not. To do this it fetches the pended IOCTL, adds some information (e.g. packet payload) to the IRP and completes the call. The user mode application can now examine the packet data and decide whether this packet needs to be modified.

    Here it gets difficult for me: How do I signal back my user mode decision to the kernel driver? I could send another IRP to the driver that the packet with a certain packet ID needs to be modified, but this would require me to queue all network packets...I would prefer to remain synchronous (e.g. to wait in my receive / send handler until a decision has been made).

    Friday, April 6, 2012 1:35 PM
  • You will need to queue the packet and wait for the inverted call to return (i.e. send an IOCTL with the decision) back to the driver.  Now since you already expressed concern about performance, one simple improvement is to have the IOCTL being pended in its input field have a tri-state variable (new IOCTL, packet modified, packet unmodified). 

    Queuing requests and packets is an intregal part of the Windows driver design.  Things by nature are asynchronous and your driver has to live with it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Friday, April 6, 2012 1:45 PM