Detective Filter Driver

Detective Filter Driver

This article is excerpted from "Windows Kernel scenario analysis-using open-source reactos"

 

As for the filter driver, it is attached to the class driver or port driver to intercept information between the class device driver and the port device driver, so as to achieve some statistics, monitoring, modification and even redirection operations. For example, if you want to encrypt the information stored on the disk, the data written to the disk by the port driver and read from the disk should be encrypted, however, the above class driver can only be processed according to the normal algorithm. In this case, you can insert a filter driver module between the two to implement all the encryption/decryption operations in this module.
The underlying modules are often complex, because such modules usually need to handle interruptions and also need to handle DPC functions, that is, "delayed procedure call )". In addition, some underlying modules also need to process DMA operations (in particular, the module that processes DMA operations is often referred to as "Adapter Driver )"). While the intermediate module, although its processing algorithms and processes may also be complex, has no such trouble as interrupt processing, DPC, or DMA.
It is necessary to note that the stacking of device drivers can be nested. What is nesting? The port driver of one device can be stacked on the driver of another device. Take the USB mouse driver as an example. From top to bottom, the first is the mouse driver class, and then the port driver of the USB mouse. However, this port driver does not directly deal with the hardware interface, because this mouse is used as a USB device, so the driver class of the USB device should be placed under this port driver module, then there is the port driver (or small port driver) of the specific USB interface chip ). In this way, two stacks are stacked together. This is the so-called nesting.
The reader may ask, since it is a port driver of the USB mouse, why not implement the driver for the USB chip by yourself? That is also acceptable, but there are two considerations here. First of all, this obviously does not conform to the Software Reuse Principle. Since we already have a USB drive class and a port drive, why do we need to implement it again? Besides, even if we want to implement it again, it is difficult to ensure its correctness. Windows Device Driver modules are not open-source software. Although these modules can be installed and used, they do not know how they are implemented. Therefore, it is not easy or economical to implement them by yourself. Second, even if it is easy and doesn't consider whether it is economical, it is still inappropriate. This is because the operation on a specific device or interface should not be "political", but should be controlled by the same module. Otherwise, you must consider how to mutex, how to serialize, and how to coordinate. These factors and measures may be taken into account in newly developed modules, but the existing modules cannot be changed. In this way, it is inevitable that existing modules should be discarded and replaced with self-developed modules. This is of course unrealistic.