请大师开坛布法，解答一下文件过滤方面的问题

1、在filemon中仅仅对IRP_MJ_系列进行处理能不能完全过滤，需要从fastio相关函数中
添加相同功能的代码否？他们是平行的功能，但是从filmon代码看来IRP_MJ_系列好像处
理权在先，但是有没有只通过fastio就能操作文件的？
2、ifs和filemon的关系如何？
3、如何判断文件操作是否由网络产生和要得到访问者的的基本信息，能给个思路否？从哪里能获取是谁在访问的信息？

也是新手上路，不是大师，来讨论一下有关的问题：）

1，FastIo是对高速缓存访问时采取的方法，与_IRP_MJ系列绝对不是平行的功能。我想如果仅仅是在高速缓冲中建立和访问的临时文件应该还是有可能只通过fastio操作的吧？不过
irp_mj系列也不仅仅是对磁盘的访问，否则就不用判断NOCATCHE、PAGING_IO之类的flags了。至于具体有什么区别和联系，还盼望大师出来结惑！
2，感觉filemon就是一个filter，建立在文件系统之上，不知道如果想把filter放在文件系统下面那一层的话，会不会很困难：）

另外IRP_NOCATCHE 和 IRP_???_PAGING_IO到底有什么区别，分别代表什么意思？

Q13 Must I support Fast I/O in my file system or filter, and where is Fast I/O documented?
Q13 我必须在我的文件系统或过滤驱动中支持Fast I/O，以及Fast I/O文档在那里？

Fast I/O is optional for a file system. For a file system filter driver, it is required if any file system it filters supports fast I/O. Because all of the standard Windows NT/2000/XP file systems support fast I/O, essentially it is required of all filter drivers.

对于一个文件系统来说Fast I/O是可选的。对于一个文件系统过滤驱动程序来说，如果它过滤的对象文件系统支持Fast I/O， 它也是需要支持的。由于所有的标准Windows NT/2k/XP 文件系统都支持Fast I/O， 从本质上来说所有的过滤驱动程序也都是需要支持的。

Fast I/O is a mechanism that was introduced into Windows NT in order to optimize the handling of certain I/O operations. In addition, fast I/O routines are also used for a variety of communications channels between the FSD and various kernel components, including the I/O Manager, the File System Runtime Library, and the CIFS File Server. Unfortunately, at the present time Fast I/O is not documented, although future versions of the IFS Kit will include documentation on how the Fast I/O routines are used.
Fast I/O是为了最优化某些I/O操作过程而在Windows NT中引入的一种机制。另外，fast I/O 例程也用来充当FSD与各种内核组件之间的各种通信通道，这些内核组件包括I/O管理器、文件系统运行时库和CIFS文件服务器。不幸的是，目前Fast I/O仍然没有相应文档，尽管未来版本的IFS Kit将会包括Fast I/O的使用文档。

ft，osr上看到的，结果好像什么都没有说明白：（

再看看这个，好像有点意思：）
Q25 What is the difference between cached I/O, user non-cached I/O, and paging I/O?
Q25 cached I/O, user non-cached I/O以及 paging I/O之间有什么区别？

In a file system or file system filter driver, read and write operations fall into several different categories. For the purpose of discussing them, we normally consider the following types:
在文件系统或者文件系统过滤驱动程序中，读和写操作分为几种不同的类型。为了便于讨论，我们通常认为有以下几种类型：

- Cached I/O. This includes normal user I/O, both via the Fast I/O path as well as via the IRP_MJ_READ and IRP_MJ_WRITE path. It also includes the MDL operations (where the caller requests the FSD return an MDL pointing to the data in the cache).
－Cached I/O。这类包括正常的用户I/O，不管是通过Fast I/O还是通过IRP_MJ_READ/WRITE 通道； 也包括了MDL操作（在这种情况下，调用者请求FSD返回一个指向高速缓存中数据的MDL指针）。


- Non-cached user I/O. This includes all non-cached I/O operations that originate outside the virtual memory system.
－Non-cached user I/O。这类包括了所有的发起与虚拟内存系统之外的 non-cached I/O操作


- Paging I/O. These are I/O operations initiated by the virtual memory system in order to satisfy the needs of the demand paging system.
－Paging I/O。这类是为了满足“请求页面调度系统”的需求而由虚拟内存系统发起的I/O操作。


Cached I/O is any I/O that can be satisfied by the file system data cache. In such a case, the operation is normally to copy the data from the virtual cache buffer into the user buffer. If the virtual cache buffer contents are resident in memory, the copy is fast and the results returned to the application quickly. If the virtual cache buffer contents are not all resident in memory, then the copy process will trigger a page fault, which generates a second re-entrant I/O operation via the paging mechanism.
Cached I/O 是任何能够被文件系统数据高速缓存处理的I/O。在这种情况下，操作通常是将数据从虚拟高速缓存的缓冲区复制到用户缓冲区。如果虚拟高速缓存的缓冲区内容是常驻内存的，复制过程师快速的并且结果将很快返回给应用程序。如果虚拟高速缓存的缓冲区内容并非全部都是常驻内存的，那么复制进程将触发一个页面错误，这将通过页面调度机制产生一个再次重入I/O操作。


Non-cached user I/O is I/O that must bypass the cache - even if the data is present in the cache. For read operations, the FSD can retrieve the data directly from the storage device without making any changes to the cache. For write operations, however, an FSD must ensure that the cached data is properly invalidated (if this is even possible, which it will not be if the file is also memory mapped).
Non-cached user I/O是必须绕过高速缓存的I/O，甚至在数据已经在高速缓存中的情况下也是如此。 对于读操作， FSD能够直接从存储设备上重新得到数据，而不必对高速缓存进行任何修改。 对于写操作， 无论如何FSD都必须保证高速缓存中的数据是完全无效的（即使这是可能的， 如果文件也是内存映射的，也不会是这样）。


Paging I/O is I/O that must be satisfied from the storage device (whether local to the system or located on some "other" computer system) and it is being requested by the virtual memory system as part of the paging mechanism (and hence has special rules that apply to its behavior as well as its serialization).
Paging I/O 是必须适应存储设备（不管是本地还是位于其他计算机系统上）的I/O，并且作为页面调度机制的一部分由虚拟内存系统提出请求（也因此具有特殊的规则以用于类似串行化之类的行为）。

这个具体说明了Paging I/O的规则，仔细研究一下：）
Q50 What are the rules for my file system/filter driver for handling paging I/O? What about paging file I/O?
Q50 对于我的文件系统/过滤驱动程序来说，处理Pagnig I/O的规则是什么？Paging file I/O呢？

The rules for handling page faults are quite strict because incorrect handling can lead to catastrophic system failure. For this reason, there are specific rules used to ensure correct cooperation between file systems (and file system filter drivers) and the virtual memory system. This is necessary because page faults are trapped by the VM system, but are then ultimately satisfied by the file system (and associated storage stack). Thus, the file system must not generate additional page faults because this may lead to an "infinite" recursion. Normally, hardware platforms have a finite limit to the number of page faults they will handle in a "stacked" fashion.
处理页面错误的规则是相当严格的，因为错误的处理可能导致灾难性的系统错误。正是由于这个原因，有详细明确的规则用于保证文件系统（过滤）驱动程序与虚拟内存系统之间正确的协作。 这是有必要的，因为页面错误是被虚拟内存系统截获的，而最终由文件系统（及相关的存储堆栈）处理的。因此，文件系统一定必要产生附加的页面错误，因为这将导致无限递归调用。 通常硬件平台有一个页面错误数目的有限限制值，？？？？？？。


Thus, the most reliable of the paging paths is that for the paging file. Any access to the paging file must not generate any additional page faults. Further, to avoid serialization problems, the file system is not responsible for serializing this access - the paging file belongs to the VM system, and the VM system is responsible for serializing access to this file (this eliminates some of the re-entrant locking problems that occur with general file access).
因此，最可靠的页面调度路径就是通过页面调度文件。 任何对页面调度文件的访问一定不要产生任何附加的页面错误。 进一步，为了避免串行化问题， 文件系统不负责将访问串行化――页面调度文件属于虚拟内存系统，而虚拟内存系统负责把对这个文件的访问串行化（这消除了出现在常规文件访问中的重入锁定问题）。

To achieve this, the drivers involved must ensure they will not generate a page fault. They must not call any routines that could generate a page fault (e.g., code modules that can be paged). The file system may only be called at APC_LEVEL but it should only call those routines that are safe to call at DISPATCH_LEVEL, since such routines are guaranteed not to cause page faults. None of the data being used through this path should be pagable.
为了达到这个目的，有关的驱动程序必须保证它们不会产生页面错误。它们一定不要调用任何可能引起页面错误的例程（例如可能被分页的代码模块）。文件系统仅可能在APC_LEVEL上被调用，但它应当仅调用哪些在DISPATCH_LEVEL上调用安全的例程， 因为这些例程能够保证不会引起页面错误。 没有任何通过这个路径被调用的数据能够被分页。


For all other files, paging I/O has less stringent rules. For a file system driver the code paths cannot be paged - otherwise, the page fault might be to fetch the very piece of code needed to satisfy the page fault! For any file system, data may be paged, since such a page fault can always be resolved eventually by retrieving the correct contents off disk. Paging activity occurs at APC_LEVEL and thus limits arbitrary re-entrancy in order to prevent calling code paths that could generate yet more page faults.
对于所有其他文件， paging I/O 有略宽松的规则。对于一个文件系统驱动程序，代码路径不能被分页，否则，页面错误应当到达恰当的代码段，用来处理这个页面错误！对于任何文件系统，数据应当被分页， 因为这样一个页面错误总是能够通过从硬盘上恢复而最终被正确的解决。页面调度活动出现在APC_LEVEL，因此为了保护也可能产生更多的页面错误的调用代码路径，它限制了任意重入。


These rules will prevent the system from processing more than two page faults in a stacked fashion within the thread context. This should be safe for all processors supported by Windows.

这一段也比较有用，嗯，呵呵，边看边贴，大家不会有什么意见吧？

For a file system filter driver that wishes to modify the data in some way, it is important to keep in mind the use of that memory. For example, a traditional mistake for an encryption filter is to trap the IRP_MJ_WRITE where the IRP_NOCACHE bit is set (which catches both user non-cached I/O as well as paging I/O) and, using the provided MDL or user buffer, encrypt the data in-place. The risk here is that some other thread will gain access to that memory in its encrypted state. For example, if the file is memory mapped, the application will observe the modified data, rather than the original, cleartext data. Thus, there are a few rules that need to be observed by file system filter drivers that choose to modify the data buffers associated with a given IRP:
对于一个希望在某处修改数据的文件系统过滤驱动程序来说，紧记内存的时候是非常重要的。例如，在一个加密过滤程序中经常出现的错误就是当IRP_NOCACHE（拦截了user non－cached I/O和Paging I/O）标志位被设置时拦截IRP_MJ_WRITE，并且使用其中的MDL或者UserBuffer，直接加密数据。这样做的危险在于一些其他线程将会在加密状态下访问这段内存，应用程序就将看到修改过的而不是原始的明文数据。 因此，以下是一些对于文件系统过滤驱动程序需要注意的规则，用来选择对一个相应给定的IRP的数据缓冲区进行修改：

? The IRP_PAGING_IO bit changes the completion behavior of the I/O Manager. MDLs in such IRPs are not discarded or cleaned up by the I/O Manager, because they belong to the Memory Manager (see IoPageRead as an example). Thus, filter drivers should be careful when setting this bit (e.g., if they create a new IRP and send it down with the resulting data).
* IPR_PAGING_IO标志位改变了I/O管理器的结束行为。 在这样IRP中的MDL 不被I/O管理器丢弃或是清除， 因为它们属于内存管理器（作为例子，可查看IoPageRead）。因此，过滤器驱动程序在设置这个标志时应当注意（例如创建一个新的IRP并将其连同结果数据传向下层）。

? The Irp->UserBuffer must have the same value as is returned by MmGetMdlVirtualAddress. If it does not and the underlying file system must break up the I/O operation into a series of sub-operations, it will do so incorrectly (see how this is handled in deviosup.c within the FAT file system example in the IFS Kit, where it builds a partial MDL using IoBuildPartialMdl. It uses Irp->UserBuffer as an index reference for Irp->MdlAddress). For example, if substituting a new piece of memory (such as for the encryption driver), make sure that this parameter is set correctly.
* Irp->UserBuffer必须与MmGetMdlVirtualAddress返回的值相同。否则下层文件系统必须中断此次I/O操作而进入到一系列子操作，它将错误的进行（参考IFS Kit中FAT文件系统的例子中deviosup.c里面是如何处理这种情况的，它使用IoBuildPartialMdl建立了一个局部MDL，并使用Irp->UserBuffer作为Irp->MdlAddress的索引参考）。例如，如果取而代之以一段新的内存（比如加密程序），确信这一参数被正确的设置。

? Never modify the buffer provided by the caller unless you are willing to make those changes visible to the caller immediately. Keep in mind that in a multi-threaded shared memory operating system the change is - literally - available and visible to other threads/processes/processors as you make them. Changes should always be made to a separate buffer component. That buffer can then be used in lieu of the original buffer, either within the original IRP, or by using a new IRP for that task.
* 绝对不要修改调用者提供的缓冲区，除非你想要使哪些修改立即对调用者可见。 紧记在一个多线程共享操作系统中，当你进行这样的修改时，这些修改――从字面上来看――是对其他线程/进程/处理器可访问和可见的。 修改总是应当在另外一个独立的缓冲区中进行，那个缓冲区随后能够被用在原始缓冲区的地方，或者是原始的IRP,或者为这一任务使用一个新的IRP。

? Use the correct routine for the type of buffer (e.g., MmBuildMdlForNonPagedPool if the memory is allocated from non-paged pool).
* 根据缓冲区类型使用正确的例程（例如如果内存是从非分页内存池中分配的，那么使用MmBuildMdlForNonPagedPool）。

? Any reference to a pointer within the user's address space must be protected using __try and __except in order to prevent invalid user addresses from causing the system to crash.
* 任何对用户地址空间中指针的引用必须使用_try和_except进行保护，目的是避免无效的用户地址导致系统崩溃。

3、如何判断文件操作是否由网络产生和要得到访问者的的基本信息，能给个思路否？从哪里能获取是谁在访问的信息？

这个我也比较迷惑,单独截获mj_create来阻止访问d:\my.txt,本地可以,可是网络上来访问192.168.1.23\d$\my.txt就没法阻止

郁闷

这个我也比较迷惑,单独截获mj_create来阻止访问d:my.txt,本地可以,可是网络上来访问192.168.1.23d$my.txt就没法阻止

郁闷

我在同一个交换机的局域网中试了一下，网络对文件的访问显示的进程是system:8 ，好像只要限制不让读网络也读不了，不让写网络也写不了，关键是要分门别类的限制需时需要知道本次访问是否源于网络？

感谢zhangc98的热心解答，3ks！

到底怎么确定当前这个mj_create是网络访问产生的阿