Hi,
I am changing an existing file filter system driver to minifilter. There is a common deadlock issue when two or more antivirus are running at the same time. When antivirus “A” want access a file, antivirus “B” block the access and try to scan, then antivirus “B” block the access and so on… This problem was solved in the current version with a shadow devices out of the filter chain. The question is, how i can solve this problem with the new minifilter model???
I am assuming you mean the case of A sits on top of B which sits on the file
system. The good news is this is handled by mini-filters look at
FltCreateFile it allows you to specify that only filters and filesystems
below you in the stack get called.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntfsd…
> Hi,
> I am changing an existing file filter system driver to minifilter. There
> is a common deadlock issue when two or more antivirus are running at the
> same time. When antivirus “A” want access a file, antivirus “B” block the
> access and try to scan, then antivirus “B” block the access and so on…
> This problem was solved in the current version with a shadow devices out
> of the filter chain. The question is, how i can solve this problem with
> the new minifilter model???
>
But in my model the scan service is in user mode so i can’t use fltcreatefile. I want do the upgrade without changing the user mode service of the antivirus.
Thanks, for your answers.
Hi!
One advantage of using the Filter manager model is that Filter generated I/Os can be sent to the MINIFILTERS below. Hence problem of reentrance from the top of the stack is removed (If one uses the model correctly).
Suppose you want to open a file. Just issue FltCreateFile(Ex). The filter manager will take care that this is sent ONLY to the minifilters below your minifilter and the legacy filters below the corresponding Filter Manager frame. Check WDK for more details.
However, the deadlock can still occur, if the OTHER antivirus filter ( or for that matter any other FS filter ) sitting below you in the stack issues a ZwXXX that will enter from the top of the stack. If it uses the shadow device concept and then issues a Zw call, then everything should work fine.
Regards,
Ayush Gupta
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@segurmatica.cu
Sent: Monday, December 10, 2007 8:04 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] writing minifilter driver for antivirus purpose
Hi,
I am changing an existing file filter system driver to minifilter. There is a common deadlock issue when two or more antivirus are running at the same time. When antivirus “A” want access a file, antivirus “B” block the access and try to scan, then antivirus “B” block the access and so on… This problem was solved in the current version with a shadow devices out of the filter chain. The question is, how i can solve this problem with the new minifilter model???
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi!
One advantage of using the Filter manager model is that Filter generated I/Os can be sent to the MINIFILTERS below. Hence problem of reentrance from the top of the stack is removed (If one uses the model correctly).
Suppose you want to open a file. Just issue FltCreateFile(Ex). The filter manager will take care that this is sent ONLY to the minifilters below your minifilter and the legacy filters below the corresponding Filter Manager frame. Check WDK for more details.
However, the deadlock can still occur, if the OTHER antivirus filter ( or for that matter any other FS filter ) sitting below you in the stack issues a ZwXXX that will enter from the top of the stack. If it uses the shadow device concept and then issues a Zw call, then everything should work fine.
Regards,
Ayush Gupta
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@segurmatica.cu
Sent: Monday, December 10, 2007 8:04 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] writing minifilter driver for antivirus purpose
Hi,
I am changing an existing file filter system driver to minifilter. There is a common deadlock issue when two or more antivirus are running at the same time. When antivirus “A” want access a file, antivirus “B” block the access and try to scan, then antivirus “B” block the access and so on… This problem was solved in the current version with a shadow devices out of the filter chain. The question is, how i can solve this problem with the new minifilter model???
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com
Then with that point the question is how to use shadow devices, or something similar, in minifilter (if there is posible) .
Regards,
Yohamnes
>> Then with that point the question is how to use shadow devices, or something similar, in minifilter (if there is posible) .
You don’t need the shadow device concept in minifilter unless you are DESPERATE to use the ZwXXX calls instead of the nice FltXXX calls.
If you read the documentation, you will yourself realize this. 
And as far as the shadow device concept is concerned you can apply it in both (minifilter and legacy filter).
The whole purpose of shadow device is to remove the problem of re-entrancy from top of the stack.
And if someone ( filter manager ) already does it for you when you call FltXXX functions, why do you want to complicate matters by using shadow device AND ZwXXX calls?
Regards,
Ayush Gupta
The desired behaviour is this. When a create IRP is received the file information is put in a queue and an event is sent to the user mode service. The service checks the file using a shadow device. On post create the IRP is blocked until the service finishes checking, then the create is allowed or disallowed.
(minifilter and legacy filter).>
As far as i know a minifilter driver does not have a device. And if it is posible how to do this.
Thanks in advance.
Yohamnes
The reason I think forces me to use shadow devices is that other AV using legacy filters (below in the chain) use ZwXXX calls. What I would like to do is to use the minifilter model, remove the shadow devices and at the same time avoid reentrancy with those AV.
Regards,
Yohamnes
I hate to be the ignorant guy who chimes in and confuses things or leads
you down the wrong path, but this sounds suspiciously similar to the
idea of adding a “control device object” to minifilter to receive ioctls
for kernel/userland communication. Take a look at the share access
discussion here: http://www.osronline.com/showthread.cfm?link=121217
If that sounds like the right idea (more or less) the CDO sample in
src/filesys/minifilter/cdo will make for informative reading as to how
to rig up the separate device.
The short answer to “does a MF driver have a device” is evidently yes,
and the callbacks you register with fltmgr appear to be completely
separate from the routines you put in the device object.
I would like to emphatically point out at this juncture, before you
start coding, that I have no idea if doing this is a good idea or
reasonable solution to your problem. If somebody else says you can
accomplish this using only the MF model, I’d take their advice over
mine.
~Eric
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@segurmatica.cu
Sent: Monday, December 10, 2007 3:42 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] writing minifilter driver for antivirus purpose
The desired behaviour is this. When a create IRP is received the file
information is put in a queue and an event is sent to the user mode
service. The service checks the file using a shadow device. On post
create the IRP is blocked until the service finishes checking, then the
create is allowed or disallowed.
in both (minifilter and legacy filter).>
As far as i know a minifilter driver does not have a device. And if it
is posible how to do this.
Thanks in advance.
Yohamnes
—
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks Eric, i was reading your post and your discovery. Certainly the documentation and the examples are very poor around this. Although i still waiting for an answer to make me do the things entirely with the new model.
Regards,
Yohamnes.
>>The reason I think forces me to use shadow devices is that other AV using legacy filters (below in the chain) use ZwXXX calls.
I am not very sure how will you remove the reentrancy from top of the stack that is caused by some OTHER antivirus ( or for that matter any other filter ) by implementing shadow device in YOUR minifilter/ filter.
I always thought that shadow device can be used to avoid reentrancy when YOU are issuing a Zw call from YOUR filter/ minifilter.
>What I would like to do is to use the minifilter model, remove the shadow devices and at the same time avoid reentrancy with those AV.
If the other AV filter is also a minifilter ( which should be most likely, because like you most of the companies are shifting/ have shifted to the minifilter model ), you don’t have to worry. That will also use FltXXX calls. And if its ALTITUDE is less than your minifilter’s ( i.e., it is lower in the minifilter stack ) you won’t see the operations issued by it.
I would suggest that you read the documentation. A lot of thing will be clear then.
Regards,
Ayush Gupta