Pipe communicate between kernel & user mode

Hi All,

I am new with driver dev, some question may be stupid but hope you could help, thanks.

I am creating a driver, and need communicate with it through user mode back & forth, with both frequently & sometimes big volume of data.

We have created an anonymous pipe in user mode, and passed this handle to kernel through IOControl.

Though, from https://community.osr.com/discussion/84676, using pipe directly in kernel mode looks not recommended, but for current design, we need stick to it.

The questions are:

  1. Since there is no funcs like GetOverlappedResult() exists, I am not clear that how to implement an asynch I/O with this pipe handle under kernel?
  2. If not use pipe directly, how can I change to IRP based communication through the pipe handle? For specific, with a buffer of data generated, how could I create a IRP and send to that pipe? And on the reverse direction, how could I capture the IRPs send to this pipe from user mode?
  3. I need Read & write with pipe asynchronously, but I have limited knowledge with Buffered IRP_MJ_READ ,Direct IRP_MJ_READ ,Buffered IRP_MJ_DEVICE_CONTROL , Direct IRP_MJ_DEVICE_CONTROL, could anyone suggest which of these methods is fit for my requirement and if there is any sample code?

Unless I’m missing some subtle issue, using a pipe for communicating between your driver and a user-mode app is a Terrible idea. Why in the world would you not simply use ReadFile, WriteFile, and DeviceIoControl functions to talk to your driver? By using a pipe, you’re incurring more than double the overhead!

BTW: Is this a file system or file system Minifilter question? Because if not, it belongs in the NTDEV category and not here (which is NTFSD).

Peter

hi Peter,

Thanks for your comments.

The whole story is we are implementing a network redirector to replace the 3rd driver, and its original design is using pipe communication. To avoid change too much on the upper layer & backward compatibility, we try to stick the pipe.

There are too little information I could found that using pipe under kernel, so I am seeking help here to see if anyone has such experience or guidance to convert pipe to IRP based one.

Indeed this is a file system driver so I am putting it here.

If it’s a file system, you should use FSCTLs to talk to it. That’s the way it’s done.

I suggest you give up on the pipe idea. Again, I might be missing something, because using a pipe to talk to a driver seems like a pretty unusual approach (unless, for example, you need to be able to talk to it from other systems on a LAN or something?)

Peter

The only kernel pipe sample I know of was one of the biggest pieces of crap I have ever encountered in 45 years of kernel work. Experimenting with it for a client 17 years ago I found over 50 major bugs, and it still crashed every version of Windows beyond NT 4.0. I would strongly urge you forget this now, or else add a few man years to your project estimate to fix it.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

Thank you Don.

Yeah, from the thread and other discussion on web, I would agree with your suggestion,

While considering our current structure, giving a pipe handle passed in, can we covert it to IRP or other com methods?

All you can do is make a user mode application to handle pipe communications, then have the application send the data to the driver using FSCTL calls as Peter suggested.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

Thanks for your valuable comments, Don & Peter.

We will re-evaluate current design and suggestions you made.

Not sure I am able/allowed to comment on there, as I’m new to Windows as well, and I had existing Unix sources to port over which meant I wanted to retain the existing ioctl work -

so I used ioctls, which can be done read/write, and I implemented copyin/copyout so it works the same; However, only used for “Session Control” here, I certainly don’t think passing IO through this way to be reasonable.

https://github.com/openzfsonwindows/ZFSin/blob/master/ZFSin/zfs/module/zfs/zfs_ioctl.c#L6431
https://github.com/openzfsonwindows/ZFSin/blob/master/ZFSin/zfs/include/sys/zfs_ioctl.h#L493
https://github.com/openzfsonwindows/ZFSin/blob/master/ZFSin/spl/module/spl/spl-windows.c#L124

You should probably not listen to me for windows code advise though.