Various questions regarding filter drivers, Mm, Cc

Hi

I am a beginner with windows programming and I have a few questions
regarding filter drivers. Please bear with me if the questions sound
insane.

I need to build a filter driver which alters the contents of a file
when it is loaded for execution. I don’t need to alter the contents
when they are read/written i.e. from ReadFile or WriteFile. From what
I have read from different sources it seems to me that:

  1. cache manager is not involved in any of these transactions. When Mm
    handles page-faults, it sends a non-cached IO request to the file
    system driver (i.e. I should be seeing NON_CACHED and PAGING_IO set in
    IRP_READ).

  2. when handling page faults, the Mm will always use IRP’s and not FastIo.

Is this understanding correct? This also leads me to believe that
image file executions are not cached by the cache manager, but if the
Mm already has a mapping for that file, it will reuse that mapping; is
this correct?

Does this also mean that if I want to stop altering contents of an
image file ‘foo’; I will also need to flush the Mm mappings, because
it might reuse the stale ones?

Thanks for your patience.

You will receive paging reads, and you will not be able to determine
whether they are from a mapped executable or just from the same file mapped as
data.

You will need a complex “FSD over FSD” filter which will create its own
FCBs to do this.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “foo bar”
To: “Windows File Systems Devs Interest List”
Sent: Monday, December 20, 2004 3:46 AM
Subject: [ntfsd] Various questions regarding filter drivers, Mm, Cc

> Hi
>
> I am a beginner with windows programming and I have a few questions
> regarding filter drivers. Please bear with me if the questions sound
> insane.
>
> I need to build a filter driver which alters the contents of a file
> when it is loaded for execution. I don’t need to alter the contents
> when they are read/written i.e. from ReadFile or WriteFile. From what
> I have read from different sources it seems to me that:
>
> 1) cache manager is not involved in any of these transactions. When Mm
> handles page-faults, it sends a non-cached IO request to the file
> system driver (i.e. I should be seeing NON_CACHED and PAGING_IO set in
> IRP_READ).
>
> 2) when handling page faults, the Mm will always use IRP’s and not FastIo.
>
> Is this understanding correct? This also leads me to believe that
> image file executions are not cached by the cache manager, but if the
> Mm already has a mapping for that file, it will reuse that mapping; is
> this correct?
>
> Does this also mean that if I want to stop altering contents of an
> image file ‘foo’; I will also need to flush the Mm mappings, because
> it might reuse the stale ones?
>
> Thanks for your patience.
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

> You will need a complex “FSD over FSD” filter which

will create its own FCBs to do this.

Well, after nearly two years of work on such filter,
I would like to add some notes.

This approach requires A LOT (repeat - A LOT) of work.
If you create a “filesystem-over-filesystem” layer,
you will have to

  1. Manage two file objects (one for you and one for lower file system)
    which leads to various recursion problems
    (lets look at IRP_MJ_CLEANUP, where you have to
    do ObDereferenceObject, which sends another cleanup)

  2. Manage cache (even if you don’t need to handle
    the cache - how you will handle this sequence
    a) cached read of EXE file (e.g. copy to disk)
    b) noncached mapping of EXE file

  3. You must prevent the lower file system to get your FCBs at all costs,
    otherwise BSOD.

  4. A very painful problem is some IOCTL calls, which have
    a HANDLE in its information structure
    (handle to filesystem’s file object with its FCBs).
    Your task will be to take this handle and replace it
    with a lower filesystem valid handle. Some IOCTLs
    are not documented, which makes your work even more
    difficult.

  5. Because of managing your own FCBs, you will have to manage
    FCB locks too. This leads to various deadlocks. with some
    obscure situations, like Offline folders.

So if you will start to do things that way, you must damn well consider
if it is really worth it. Also remember that you will need at least
two-three years for making a version which works stable.
I really see this way of writing filter as a road to hell,
and I will try to rewrite the filter when I will have time.

L.