none
Accessing a user-space socket from within a kernel driver RRS feed

  • Question

  • Coming from a *nix background i'm having to learn quite a few things. The question i have is how do i read/write to a socket within a kernel driver when the original socket was created by user space.

    To explain better, the user daemon listens on a particular port and when the connection is established and after the necessary checks, the client socket fd is passed to the kernel module. The kernel module is in charge of data transfers but it is easier for us to keep the user daemon do certain tasks which are relevant only to user space before passing the socket to the kernel. 

    In Linux within kernel space we call fget(fd) which gives a file pointer, this file pointer can be used with the kernel socket apis. For example the equivalent of recvmsg in kernel is sock_recvmsg() etc.

    I understand that WinSock Kernel (WSK) is what is need for sockets at the kernel level and Windows Sockets 2 (WinSock) is what i need at the user level (mostly similar to the UNIX socket APIs which is quite helpful). Is it possible to do what i'm looking for ?

    Moving everything to kernel space is an option but hopefully there are other possibilities.

    Target OS is Windows 8 and Server 2012.

    Cheers,

    Friday, January 3, 2014 12:34 PM

Answers

  • So instead of using the user space socket call to listen on the port, create a wrapper DLL with similar functions whose implementation is a set of IOCTL's to the kernel mode driver.  This should keep your current code pretty much intact without trying to go in undocumented features of sockets implementations to try to exactly mimic your Unix implementation.

    My rule on taking code from Unix implementations, is to take the algorithm (this may include a lot of "pure C" code), but don't try to take the implementation or API's. 


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

    • Marked as answer by Pentd Friday, January 3, 2014 2:19 PM
    Friday, January 3, 2014 1:29 PM

All replies

  • Having user space helper applications are a good idea.  I am wondering in this case if you have thought about splitting the work somewhat differently.  How about putting all the socket calls into the kernel mode driver, and providing an interface for the user space application to access the socket when appropriate?   This should have little or no increase in overhead versus a standard socket call if done correctly, and it eliminates the problem of sharing the socket.


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

    Friday, January 3, 2014 12:44 PM
  • The user daemon once it passes the socket to the kernel, no longer needs it. The reason for the user daemon is its simpler, has access to databases, files etc. Also not all connections to the user daemon need to be handled by the kernel module.

    The design does require a rethink, but if i could maintain the older design, i could go ahead with a lot of the remaining porting effort and then come back to this.

    Ideally

    1. The kernel module listens on the port

    2. Process a client socket, recevies data, pushes this to the user daemon for its usual processing

    3. Once we are good to go, then the kernel module takes control of the socket with no further communication required with the user daemon.

    Right now we have

    1. The user daemon listens on that port

    2. Recevies a client connection, does its initial validations,

    3. If everything required is received, the socket is passed on to the kernel module and it no longer requires to use the socket.

    Friday, January 3, 2014 1:17 PM
  • So instead of using the user space socket call to listen on the port, create a wrapper DLL with similar functions whose implementation is a set of IOCTL's to the kernel mode driver.  This should keep your current code pretty much intact without trying to go in undocumented features of sockets implementations to try to exactly mimic your Unix implementation.

    My rule on taking code from Unix implementations, is to take the algorithm (this may include a lot of "pure C" code), but don't try to take the implementation or API's. 


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

    • Marked as answer by Pentd Friday, January 3, 2014 2:19 PM
    Friday, January 3, 2014 1:29 PM
  • Yes, seems the right way forward. Thanks !
    Friday, January 3, 2014 2:20 PM