In my PostCreate I get the name of the file and send it to the user mode where I am open the file. After a short time the entire computer hangs.
Can or should I send the file handle to the user mode instead?
Regards
Mattias Bergkvist
Or should I call FltReadFile to read the entire file and send it to the user mode instead of sending the handle/file name and read the file in user mode?
Which way has the best performance?
Regards
Mattias Bergkvist
Hi Mattias,
In my PostCreate I get the name of the file and send it to the user mode where I am open the file. After a short time the entire computer hangs.
Consider this situation. A user app X send an open request for file F1. In your post create, you send the name of the file to your user mode app. Your app sends a request to reopen it. You are in post create once again. Suppose you are not checking that it is in the context of your app, then you are stuck; you will again send it to your app to reopen the file. And the DANCE will continue. 
But anyways you won’t be making such a mistake of not identifying your own app.
Consider another situation in which there are two antivirus filters and both use the same methodology as you propose.
Let’s say your minifilter is M1 and the other is M2. And suppose M1 is at a higher altitude than M2.
Suppose both of them have corresponding user mode apps, A1 & A2.
- Let’s say an app A requests a file open.
- The PostCreate for M2 is called first, since it is lower in the stack.
- Now M2 sends the file name to its app A2 to re-open it.
- You will again see a file open in your PreCreate for this file name in context of A2.
- Again, M2s PostCreate will be called first. It will be able to identify that it is from its own app and let it go.
- Then M1s (your minifilter’s) PostCreate will be called in the context of A2. You will send the file name to your app A1 to reopen the file.
- Now A1 issues a file open. M2 does not know anything about A1. The process will be repeated from step 3
And the DANCE starts once again.
Although there are ways to avoid these kind of problems, but my objective was to bring to you such problems.
I might have gone wrong somewhere, but I hope I was able to explain my point.
Regards,
Ayush Gupta
Hi Mattias,
Or should I call FltReadFile to read the entire file and send it to the user mode instead of sending the handle/file name and read the file in user >mode?
Hmm… Do you propose to read the entire file in PostCreate and then send the contents to user mode app? What is the file is very large?
You may need a VERY LARGE buffer for sending the contents of the entire file.
Generally you would like to make your scanning library common for real-time scanning and on-demand scanning.
I would suggest you to expose functions from your minifilter which your user mode app could call.
In case of real time scanning, the app will call YourMinifilterReadFile function instead of ReadFile to read the file.
The basic theme is that in PostCreate you will return a handle to your app. Your app will call YourMinifilterReadFile with this handle to read the file.
I hope you get the idea…
Regards,
Ayush Gupta
You are a great person Ayush, thanks for all the help
Only so I get it all right.
In my PostCreate I send the filename to the user app and from my user app I call the MinifilterReadFile that return the entire file to the user app?
Maybe it is not the right forum to ask but how can I get the handle to the minifilter and how shall I use it?
Best Regards
Mattias Bergkvist
Hi Mattias,
In my PostCreate I send the filename to the user app and from my user app I call the MinifilterReadFile that return the entire file to the user app?
Actually instead of returning the file name to the user app, you can send the file handle/ object that you have got in post create. And then from your user app, you can send it to the MinifilterReadFile. You can communicate using communication ports. Its properly documented in WDK.
From your MinifilterReadFile, you can actually call FltReadFile, with the specified length, etc…
There may be other better ways of doing scanning in user mode, but I have done using this approach in the past. But my code did not really go into the market… :-).
It was just for fun that I wrote the real time scanner.
And at last you always have the option of doing whatever you want by prompting at the installation time “An incompatible product exists… Kindly uninstall it to continue installing this product.” and then ASSUME (a terrible mistake) that only we will be playing around in the file system stack apart from the FSD.
Regards,
Ayush Gupta
But if I send the handle back to the minifilterRead I still doesn’t get the content of the file in user mode. Or have I misunderstand you?
Yes of course I shall use communication ports
Best Regards
Mattias Bergkvist
You can’t really send a handle back from the kernel mode to user mode app. AFAIK, at most, you can able to duplicate the handle from kernel mode into the handle table of the user mode process. This however might pose some security risks. To perform the duplication you need to open the user mode process then perform a handle duplication.
Sandor LUKACS
Hi Sandor,
You can’t really send a handle back from the kernel mode to user mode app. AFAIK, at most, you can able to duplicate the handle from kernel mode into >the handle table of the user mode process. This however might pose some security risks. To perform the duplication you need to open the user mode >process then perform a handle duplication.
The app will not use the handle directly to open files. It would send it back to our minifilter’s MnifilterReadFile routine which in turn will call FltReadFile function using this handle. For ensuring that it is not usable outside kernel, use the OBJ_KERNEL_HANDLE. And if you want more security, you may just encrypt the handle and then send it back to user app and then when you receive it in your MinifilterReadFile routine, decrypt it and use it.
Regards,
Ayush Gupta
Hi Mattias,
But if I send the handle back to the minifilterRead I still doesn’t get the content of the file in user mode. Or have I misunderstand you?
MinifilterReadFile is a function that will be called by your user app instead of ReadFile.
Suppose, in a scanning algorithm, if your user app requires to read the file header to check whether it is a PE file, it can issue MinifilterReadFile instead of ReadFile at that point. Basically it ACTS like a wrapper function (not exactly). This function then calls FltReadFile, and then whatever data is read along with the length of the data read and other status information is returned to the user app.
Regards,
Ayush Gupta
It’s always best to keep things simple.
With that said, it would be easiest and best for you just to capture the
filename in pre-create and pass it via the
completionContext parameter, or use the FltGetFileName— functions in your
post-create and then send that to
usermode.
As Ayush was saying, look at your process id during create, kinda like how
the scanner sample does. When your
usermode app opens the file in question, if the PID matches just ignore
everything and don’t do any scanning.
The easiest thing I’ve found to do was construct a file name in the format
of ‘volume guid’ & path. All the usermode
functions will accept this format with the exception of the SFC api’s - but
I doubt you’ll be using those. Just pass that
string up - performance wise I didn’t see any notaciable impact with using
this method to generate hashes of ever file
opened compared to other methods.
Good Luck,
Matt
----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Thursday, January 17, 2008 7:13 AM
Subject: RE:[ntfsd] Can or should I send the file handle to the user mode
instead of the file name?
But if I send the handle back to the minifilterRead I still doesn’t get the
content of the file in user mode. Or have I misunderstand you?
Yes of course I shall use communication ports
Best Regards
Mattias Bergkvist
—
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Your explanation has definitely made things confusing. You can;t call the
minifilter read from the monitoring application without a handle, and you
are definitely making things hard. To the OP consider the following model:
-
At post create, put the pointer to the file object in a table. Then
notify the monitoring application of the file with whaterver data you want
and the index in the table of the file object. -
The monitroing application, can then call back to the filter with a
private interface with the index to read a region of the file (obviously you
have to provide position, size and buffer with the call). -
The monitoring application when done with the file calls with the
private interface to release the file object and allow the original create
to complete.
Obviously this is a simplification, but the basic logic like that, You do
not want to passing handles, or file object pointers or such to a user
application. Also your mini-filter needs to have a good model for knowing
the monitoring application has failed / hung so that you do not lock the
whole computer.
–
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
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
Hi Mattias,
>But if I send the handle back to the minifilterRead I still doesn’t get the
>content of the file in user mode. Or have I misunderstand you?
MinifilterReadFile is a function that will be called by your user app
instead of ReadFile.
Suppose, in a scanning algorithm, if your user app requires to read the file
header to check whether it is a PE file, it can issue MinifilterReadFile
instead of ReadFile at that point. Basically it ACTS like a wrapper
function (not exactly). This function then calls FltReadFile, and then
whatever data is read along with the length of the data read and other
status information is returned to the user app.
Regards,
Ayush Gupta
This is what I trying to do:
I have a small algorithm that requires the entire file to be able to calculate a value.
If then the value are matched I shall cancel the create.
Should I place my algorithm in the kernel mode instead and only send the hash to the user mode?
Best Regards
Mattias Bergkvist
Hi Matt,
With that said, it would be easiest and best for you just to capture the
filename in pre-create and pass it via the completionContext parameter,
or use the FltGetFileName— functions in your
post-create and then send that to usermode.
Reopening the file from user mode will still have a problem. Read the third post of this thread. I have explained a situation where there are two filters in the stack.
Regards,
Ayush Gupta
Hi Don,
Your explanation has definitely made things confusing. You can;t call the
minifilter read from the monitoring application without a handle, and you
are definitely making things hard.
Actually this is not a real minifilter read. This is actually one of the functions that will get called when your user app communicates with the minifilter using communication port. Or in the legacy model you may assume that this is one of the routines that handles a IOCTL issued by the user app.
Maybe I made my point clear. J
Hmm. The terminology used was not very good.
“Private interface” is a better and a more applicable term. J
Regards,
Ayush Gupta
RE: [ntfsd] Can or should I send the file handle to the user mode instead of the file name?So, why don’t you make it open source or donate your code to www.clamwin.net? As far as I know they’re announcing an OA scanner since when?
“Ayush Gupta” wrote news:xxxxx@ntfsd…
It was just for fun that I wrote the real time scanner.
A lot of us do things for fun or to learn something, just because we aren’t
paid for it now does not mean we want to give it away.
–
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
“frank” wrote in message news:xxxxx@ntfsd…
RE: [ntfsd] Can or should I send the file handle to the user mode instead of
the file name?So, why don’t you make it open source or donate your code to
www.clamwin.net? As far as I know they’re announcing an OA scanner since
when?
“Ayush Gupta” wrote news:xxxxx@ntfsd…
It was just for fun that I wrote the real time scanner.
Hi Don,
What you told was exactly what I meant. I really need to work on the way I
state things… :-). I re-read the stuff and it really is sort of
confusing…
Perhaps your way of maintaining a table is better than sending back and then
receiving the handle.
This has lesser security issues. Only the index is passed and not the file
object/ handle.
Regards,
Ayush Gupta
Ayush,
I figured you knew what you were saying but I’ve been there and it took
a couple of tries to follow the logic. Keep posting and you will get
practice as people ask for more explanation, your approach is right on.
I always use tables with indices that I control, since then I can
provide error handling and verification that is otherwise hard to do.
–
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
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Hi Don,
>
> What you told was exactly what I meant. I really need to work on the way I
> state things… :-). I re-read the stuff and it really is sort of
> confusing…
>
> Perhaps your way of maintaining a table is better than sending back and
> then
> receiving the handle.
> This has lesser security issues. Only the index is passed and not the file
> object/ handle.
>
> Regards,
> Ayush Gupta
>
>
RE: [ntfsd] Can or should I send the file handle to the user mode instead of the file name?I understand the concept of two filters in the stack and the potential for a deadlock. In one
of your previous post you mentioned to check for conflicting products during install. This is
what most AV’s do, and in reality these problems will always exist in the storage stack.
There are many ways to alleviate problems here, but some of them cause a double read.
For someone that is obviously writting their first file system filter the simplest appoach
would be the best for them in my view.
Regards,
Matt
----- Original Message -----
From: Ayush Gupta
To: Windows File Systems Devs Interest List
Sent: Thursday, January 17, 2008 8:07 AM
Subject: RE: [ntfsd] Can or should I send the file handle to the user mode instead of the file name?
Hi Matt,
With that said, it would be easiest and best for you just to capture the > filename in pre-create and pass it via the completionContext parameter, > or use the FltGetFileName— functions in your > post-create and then send that to usermode.
Reopening the file from user mode will still have a problem. Read the third post of this thread. I have explained a situation where there are two filters in the stack.
Regards,
Ayush Gupta
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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com