I am currently using a technique for passing data from my user-mode app
to the filter driver which appears to work fine on all platforms, but is
falling foul of Verifier on WS2008 (I suspect Vista onwards, but haven’t
tested on Vista yet.)
The FD has a FileObject from a prior call to FltCreateFile. When the
user-mode app wants to write data to this file, it sends it in a packet
using FilterSendMessage, which the FD sees in its message callback
routine. This runs in kernel mode (obviously) in the context of the
user-mode app’s thread that called FilterSendMessage. The part of the
message which contains the file data is written using FltWriteFile. All
this appears to work fine.
The problem is that the IRP checking in WS2008 Verifier spots that I
have supplied a user-mode address as the buffer address, but in kernel
mode. For example…
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.
This is because the driver was specified in the registry as being
suspect (by the administrator) and the kernel has enabled substantial
checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA will be among the most commonly seen crashes.
Arguments:
Arg1: 000000e2, IRP field is a user-mode address but Irp->RequestorMode
is KernelMode.
Arg2: 96e50e70, IRP address.
Arg3: 0100caf0, User-mode address present as the value of an IRP field.
Arg4: 00000000
So I guess I have two questions:
(1) Is what I am doing intrinsically wrong or bad?
(2) If not, is there any way I can prevent Verifier from being too picky?
The only thing which comes to mind at present is to call
MmIsDriverVerifyingByAddress() and do a buffer copy if my driver is
being verified, but this seems bad in itself!
Apologies for asking just before Plugfest, but I’d like to get this one
nailed in the kit I bring to said Plugfest!
Thanks for any insights…
John
Win7’s Verifier is much more aggressive about flagging the use of user mode
handles and buffers. In this case you’re opening the system up to crashes,
for example with a requestor mode of kernel mode drivers aren’t going to
access the data buffer under an SEH block. Thus, even if you fully verify
the buffer before sending the I/O there’s still a potential issue.
Options I can think of would be to double buffer or build an MDL to the user
data buffer and map a KVA to it (which is probably what I’d try first).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“John Leonard” wrote in message
news:xxxxx@ntfsd…
> I am currently using a technique for passing data from my user-mode app to
> the filter driver which appears to work fine on all platforms, but is
> falling foul of Verifier on WS2008 (I suspect Vista onwards, but haven’t
> tested on Vista yet.)
>
> The FD has a FileObject from a prior call to FltCreateFile. When the
> user-mode app wants to write data to this file, it sends it in a packet
> using FilterSendMessage, which the FD sees in its message callback
> routine. This runs in kernel mode (obviously) in the context of the
> user-mode app’s thread that called FilterSendMessage. The part of the
> message which contains the file data is written using FltWriteFile. All
> this appears to work fine.
>
> The problem is that the IRP checking in WS2008 Verifier spots that I have
> supplied a user-mode address as the buffer address, but in kernel mode.
> For example…
>
> DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
> A device driver attempting to corrupt the system has been caught.
> This is because the driver was specified in the registry as being suspect
> (by the administrator) and the kernel has enabled substantial checking of
> this driver.
> If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA
> will be among the most commonly seen crashes.
> Arguments:
> Arg1: 000000e2, IRP field is a user-mode address but Irp->RequestorMode is
> KernelMode.
> Arg2: 96e50e70, IRP address.
> Arg3: 0100caf0, User-mode address present as the value of an IRP field.
> Arg4: 00000000
>
> So I guess I have two questions:
>
> (1) Is what I am doing intrinsically wrong or bad?
> (2) If not, is there any way I can prevent Verifier from being too picky?
>
> The only thing which comes to mind at present is to call
> MmIsDriverVerifyingByAddress() and do a buffer copy if my driver is being
> verified, but this seems bad in itself!
>
> Apologies for asking just before Plugfest, but I’d like to get this one
> nailed in the kit I bring to said Plugfest!
>
> Thanks for any insights…
>
> John
>
>