Understand that in the minifilter communication ports, which use an
inverted call model as Tony pointed out, everything is initiated from
user mode. The service must call into the kernel to begin with for these
approaches. For the ‘inverted’ aspect (outside of the minifilter ports),
the driver would pend this request, stashing the Irp away in some list.
When it wants to ‘ask’ the user mode service to do some work, it
populates this Irp with appropriate information and then completes it.
The user mode service can then process the request and respond with a
result.
The minifilter communication ports are the same. The service calls into
the driver asking for a request to process. This request is pended by
the filter mgr framework. When the driver sends a request to the service
via this port, the framework grabs this pended request, populates the
necessary context information and returns back to user mode.
So understand, that in either situation things are started from user
mode. There is no documented way to simply have a kernel mode driver
call a user mode routine to process a request in user mode. There are
ways to do this, it happens all the time for thread creation, but these
are fully unsupported and undocumented methods. That said, if you don’t
want to use the minifilter comm ports, implement your own inverted call
model using IOCtls but in the end, it will gain you little flexibility
over the minifilter comm ports.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: xxxxx@yahoo.com
To: “Windows File Systems Devs Interest List”
Sent: 10/28/2016 9:12:30 PM
Subject: RE:[ntfsd] Inverted Call Model implementation for a minifilter,
or a possible alternative?
>Thanks for the reply tony,
>
>I want the both sides(kernel and user) to be able to initiate the
>communication. But the issue I’m asking about here is how the kernel
>can be the initiator.
>
>>Filter Manager ports are actually just an implementation of inverted
>>call in any case.
>
>As I understand from reading Inverted method call, it is a way to allow
>the kernel to “signal user” or “initiate a communication”(that’s why it
>is called inverted. because the direction of communication is made
>inverted). But as I see communication ports, the user mode will be the
>initiator of the communication and I don’t know if I can pend a message
>like what was done in inverted call model or not to make the direction
>of the communication inverted and let the kernel be the initiator.
>
>>Mini-filters can use inverted call model; I’ve done so in the past
>>successfully.
>
>I’m really not that much experienced with kernel mode drivers and just
>started digging into minifilters. I thought there might be some
>conflicts between filter manager and the sample code provider for
>inverted model, specially where they declare the IO request processing
>queue(WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE) and set an event
>processing callback(queueConfig.EvtIoDeviceControl =
>InvertedEvtIoDeviceControl;) Can these two really live together?
>
>In case you want to know what is the reason I want this type of
>communication let me explain it a bit.
>I want to send some sort of calculation and logic which can be done in
>user mode out of kernel, so the minifilter needs to be able to ask
>user-mode for some service.
>
>—
>NTFSD is sponsored by OSR
>
>
>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:>