User-Kernel Communication

Hi All,

I’m trying to get some design opinion about usr/krnl communication,
and I know, or at least used to know that there are a few different
options -

  1. Using IOCTL
  2. Shared Memory
  3. Inverted Call
  4. Optionally any other.

Basically the kernel component will try to pump continuous data
payload to the user mode components. Kernel component would be based
on Wdf.

Is there any suggestion or pointer to docs, that sheds light on high
bandwidth transactions from kernel to user mode apps ? Only few
commands, ack/nack will come to the kernel mode from user apps.

TIA,
Prokash

While I always urge caution on shared memory this sounds like one of the cases for it. I would use IOCTL’s for the user mode to kernel communication (use FASTIO if you need low overhead) and use the shared memory for the data from the kernel.

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 Prokash Sinha xxxxx@lists.osr.com
Sent: Friday, August 11, 2017 7:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] User-Kernel Communication

Hi All,

I’m trying to get some design opinion about usr/krnl communication, and I know, or at least used to know that there are a few different options -

1) Using IOCTL
2) Shared Memory
3) Inverted Call
4) Optionally any other.

Basically the kernel component will try to pump continuous data payload to the user mode components. Kernel component would be based on Wdf.

Is there any suggestion or pointer to docs, that sheds light on high bandwidth transactions from kernel to user mode apps ? Only few commands, ack/nack will come to the kernel mode from user apps.

TIA,
Prokash


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Prokash Sinha wrote:

Is there any suggestion or pointer to docs, that sheds light on high
bandwidth transactions from kernel to user mode apps ? Only few
commands, ack/nack will come to the kernel mode from user apps.

What do you mean by “high bandwidth”?

Is the data coming from a device, or generated by the kernel component?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim, it will be coming from a kernel component, as such no hardware
devices involved except some hw devices are contributors to the
traffic.

-pro

On Fri, Aug 11, 2017 at 5:49 PM, Tim Roberts
wrote:
> Prokash Sinha wrote:
>> Is there any suggestion or pointer to docs, that sheds light on high
>> bandwidth transactions from kernel to user mode apps ? Only few
>> commands, ack/nack will come to the kernel mode from user apps.
>
> What do you mean by “high bandwidth”?
>
> Is the data coming from a device, or generated by the kernel component?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Thanks Don.

Would consider this. Make sense.

Pro

On Fri, Aug 11, 2017 at 4:31 PM, Don Burn
wrote:
> While I always urge caution on shared memory this sounds like one of the cases for it. I would use IOCTL’s for the user mode to kernel communication (use FASTIO if you need low overhead) and use the shared memory for the data from the kernel.
>
>
> 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 Prokash Sinha xxxxx@lists.osr.com
> Sent: Friday, August 11, 2017 7:03 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] User-Kernel Communication
>
> Hi All,
>
> I’m trying to get some design opinion about usr/krnl communication, and I know, or at least used to know that there are a few different options -
>
> 1) Using IOCTL
> 2) Shared Memory
> 3) Inverted Call
> 4) Optionally any other.
>
> Basically the kernel component will try to pump continuous data payload to the user mode components. Kernel component would be based on Wdf.
>
> Is there any suggestion or pointer to docs, that sheds light on high bandwidth transactions from kernel to user mode apps ? Only few commands, ack/nack will come to the kernel mode from user apps.
>
>
> TIA,
> Prokash
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:>

Shared memory seems to be the right way to go here,Pro…

For the purposes of simplicity you can implement it as an outstanding DIRECT_IO IOCTL that you pend in your driver, effectively getting a shared buffer that you can use for (possibly bi-directional) long-term communications between your app and kernel

Anton Bassov

Anton, I think so too. Mainly because high intensity traffic. As Don
pointed out the cmd+cntl would be using IOCNTL, a good separation of
concern! Yeah, reading back those beautiful and short articles from
the past issues of NT Insider.

I just want to have a separate communication driver, with shared
contexts, so that I can have multiple drivers feeding to the
communication driver using shared context(s), mainly Queues ADT. The
communication driver’s sole responsibility would be cross the boundary
to user space.

Kinda got the idea, should be able to move and prototype. Basically,
this is the design idea, I already implemented in Apple platform, and
don’t want to break the architecture since it is working fairly
reliably, but being MACH & BSD driven kernel the implementation is
different, but the architecture is intended to be same.

Thanks to all of you!
-Pro

On Fri, Aug 11, 2017 at 9:45 PM, xxxxx@hotmail.com
wrote:
> Shared memory seems to be the right way to go here,Pro…
>
> For the purposes of simplicity you can implement it as an outstanding DIRECT_IO IOCTL that you pend in your driver, effectively getting a shared buffer that you can use for (possibly bi-directional) long-term communications between your app and kernel
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

> I just want to have a separate communication driver, with shared contexts, so that

I can have multiple drivers feeding to the communication driver using shared context(s),
mainly Queues ADT. The communication driver’s sole responsibility would be cross the
boundary to user space.

Are you trying to develop some kind of “NETLINK for Wndows” (at least conceptually, i.e. some generic mechanism for high-volume KM/UM communications that different apps and drivers can use)?

Anton Bassov

Yep, that’s the idea. So I was thinking about WSK too, but may be too much …

-Pro

On Fri, Aug 11, 2017 at 10:35 PM, xxxxx@hotmail.com
wrote:
>
>> I just want to have a separate communication driver, with shared contexts, so that
>> I can have multiple drivers feeding to the communication driver using shared context(s),
>> mainly Queues ADT. The communication driver’s sole responsibility would be cross the
>> boundary to user space.
>
>
>
> Are you trying to develop some kind of “NETLINK for Wndows” (at least conceptually, i.e. some generic mechanism for high-volume KM/UM communications that different apps and drivers can use)?
>
>
> Anton Bassov
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

>So I was thinking about WSK too, but may be too much

I would rather do things from the scratch…

I would write a “communication” driver that deals with KM components on the lower edge and with UM apps on the upper one. On the userland side I would encapsulate all the actual dealing with the device in a library, effectively insulating the apps from all the “gory details” pretty much the same way Winsock API does - after all, socket-based client apps don’t have to know that they are actually dealing with AFD.SYS behind the scenes, do they. I would apply the same logic here, and expose the whole thing in API that is reminiscent of the socket one (in this particular case it most certainly has to implement mmap() call, don’t you think). In fact, if you are adventurous character you can go as far as implementing signal delivery (as an “inverted call”) and select()/poll() API
(as an IOCTL).

On the KM side I would implement an internal IOCTL that returns a pointer to the table of function pointers to a caller, effectively implementing an interface of my own choice ( I guess NETLINK,again, can be used as a reference here)

The “only” question is why should one bother himself with doing something like that, taking into account that we are speaking about a third-party driver that runs under the proprietary OS.After all, there are not that many drivers and apps that may potentially make any use of this framework,don’t you think…

Anton Bassov

Sure you can try your ideas …

I know who would be using, when, how etc. So that is not the problem.

Much of what you said is correct at the architecture level, but there
are alternatives to it too :slight_smile:

And I sure will have to deal with Linux, after I’m done with this. So
the order is Mac, Window, Linux. Permutation is fixed for me by
others…

Let’s see …

-Pro

On Sat, Aug 12, 2017 at 10:04 PM, xxxxx@hotmail.com
wrote:
> >So I was thinking about WSK too, but may be too much
>
>
> I would rather do things from the scratch…
>
>
> I would write a “communication” driver that deals with KM components on the lower edge and with UM apps on the upper one. On the userland side I would encapsulate all the actual dealing with the device in a library, effectively insulating the apps from all the “gory details” pretty much the same way Winsock API does - after all, socket-based client apps don’t have to know that they are actually dealing with AFD.SYS behind the scenes, do they. I would apply the same logic here, and expose the whole thing in API that is reminiscent of the socket one (in this particular case it most certainly has to implement mmap() call, don’t you think). In fact, if you are adventurous character you can go as far as implementing signal delivery (as an “inverted call”) and select()/poll() API
> (as an IOCTL).
>
>
> On the KM side I would implement an internal IOCTL that returns a pointer to the table of function pointers to a caller, effectively implementing an interface of my own choice ( I guess NETLINK,again, can be used as a reference here)
>
>
>
> The “only” question is why should one bother himself with doing something like that, taking into account that we are speaking about a third-party driver that runs under the proprietary OS.After all, there are not that many drivers and apps that may potentially make any use of this framework,don’t you think…
>
>
>
>
> Anton Bassov
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>