FilterSendMessage type of I/O

Is FilterSendMessage using BUFFERED, DIRECT or NEITHER I/O to communicate? Internally it’s just a DeviceIoControl() call from user mode isn’t it?

It is DeviceIoControl. I guess it’s neither IO (both the send and the receive should be neither IO).

Thanks,
Alex.

Technically it is Neither I/O, though with one minor difference: Filter
Manager validates the user supplied data buffers with
ProbeForRead/ProbeForWrite before calling your callback. This is distinct
from, “true” Neither I/O where this step is not performed by the I/O
Manager.

Minor point, but worth noting (especially if you’re doing a code review).
Note that this is described in the FltCreateCommunicationPort documentation:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff541931(v=vs.85).aspx

-scott

wrote in message news:xxxxx@ntfsd…

It is DeviceIoControl. I guess it’s neither IO (both the send and the
receive should be neither IO).

Thanks,
Alex.

The ProbeForRead() / ProbeForWrite() calls just check whether the address from user mode has been committed in any way? Or is it also important that this address is not swapped out? ( Depending on the current IRQL, a swap in should be ok?

Is it possible that the “callback” runs in a different process context than the caller of DeviceIoControl() - leading, in worst case, to read random data and act on them?

In case of FltSendMessage no DeviceIoControl has to occur? The filter manager simply copies the buffer into user space after validating the addresses, is this correct?

>The ProbeForRead() / ProbeForWrite() calls just check whether the address

from user mode has been committed in any way? Or is it also important that
>this address is not swapped out? ( Depending on the current IRQL, a swap
in should be ok?

From the docs:

The ProbeForRead routine checks that a user-mode buffer actually resides in
the user portion of the address space, and is correctly aligned.
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff559876(v=vs.85).aspx)

The ProbeForWrite routine checks that a user-mode buffer actually resides in
the user-mode portion of the address space, is writable, and is correctly
aligned.
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff559879(v=vs.85).aspx)

Is it possible that the “callback” runs in a different process context than
the caller of DeviceIoControl() - leading, in worst case, to read random
data >and act on them?

The callback is designed to run in the context of the requestor. Your code
still needs to be hardened against invalid data from the user, however.

In case of FltSendMessage no DeviceIoControl has to occur? The filter
manager simply copies the buffer into user space after validating the
>addresses, is this correct?

I believe that the messaging protocol uses an inverted call model, thus
FltSendMessage will ultimately complete an IRP to send the message to user
mode.

-scott

wrote in message news:xxxxx@ntfsd…

The ProbeForRead() / ProbeForWrite() calls just check whether the address
from user mode has been committed in any way? Or is it also important that
this address is not swapped out? ( Depending on the current IRQL, a swap in
should be ok?

Is it possible that the “callback” runs in a different process context than
the caller of DeviceIoControl() - leading, in worst case, to read random
data and act on them?

In case of FltSendMessage no DeviceIoControl has to occur? The filter
manager simply copies the buffer into user space after validating the
addresses, is this correct?

That’s right, FltSendMessage works by completing the IOCTL IRP sent by FilterGetMessage after putting the message data into its buffer. That’s why FltSendMessage has a timeout. There has to be somebody waiting to get the message, otherwise the message has nowhere to go.

Christian [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.

Okay so lets summarize the cases:

FilterGetMessage is called:

  • DeviceIoControl occurs
  • FilterManager Callback for IRP_MJ_DEVICE_CONTROL is called
  • Storing the buffer pointers and a event into a queue - waiting for this event
    FltSendMessage is called:
  • Checking the queue for a entry
  • Probing and filling buffers
  • signal the event
  • Further suspended IRP_MJ_DEVICE_CONTROL callback is finished

If it’s implemented this way hopefully this is thread safe. But then why is the mini filter sampled using IoCompletionPorts… and not just waiting with multiple FilterGetMessage parallel in many threads. ( The requests should be queued in kernel?! )

with mini filter sample i mean the mini spy sample