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

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

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Pipe communicate between kernel & user mode

Atoboo_WeiAtoboo_Wei Member - All Emails Posts: 6
via Email in NTFSD
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?

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,016
    edited November 2018

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Atoboo_WeiAtoboo_Wei Member - All Emails Posts: 6
    via Email
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,016

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Don_BurnDon_Burn Member - All Emails Posts: 1,707
    via Email
    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
  • Atoboo_WeiAtoboo_Wei Member - All Emails Posts: 6
    via Email
    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?
  • Don_BurnDon_Burn Member - All Emails Posts: 1,707
    via Email
    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
  • Atoboo_WeiAtoboo_Wei Member - All Emails Posts: 6
    via Email
    Thanks for your valuable comments, Don & Peter.

    We will re-evaluate current design and suggestions you made.
  • Jorgen_LundmanJorgen_Lundman Member - All Emails Posts: 47

    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.

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!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA