Windows WDM Driver Design

Looking back at Microsoft's 10 years of development model development from VxD-> WDM-> WDF, development tools from VtoolsD --> DDK --> wdk, in this process, there are some excellent development tools, such as WinDriver and Driver Studio 3.2. WinDriver is suitable for debugging hardware. Driver Studio 3.2 adopts the C ++ development framework. You only need to write a few callback functions to write the driver, however, the impact of the new Microsoft Driver Model WDF was not developed. The final version was fixed at 3.2. I learned the driver program first through Driver Studio.

Since Windows 2000, the development of drivers is based on WDM, but it is difficult to develop. To improve this situation, Microsoft launched WDF, which is based on WDM for modeling and encapsulation, does it reduce development.

(1) the WDF driver model is introduced to the Windows WDF driver program design. The following describes the differences between the WDM Driver Model and the WDF driver model;

1) WDF uses Object-based technology to encapsulate WDM, including attributes, methods, and events. attributes are like member variables in C ++ classes, the method is like a member function in the C ++ class. An event is a callback function;

2) whether it is a kernel-mode driver or a user-mode driver, it is constructed using the same object model and carries the same base. This is based on WDF. WDF includes kmdf and umdf, both of which inherit WDF, regardless of the Framework, internal encapsulation method or WDM.

3) the WDF Driver Model encapsulates many common functions, such as PNP management and power management. In the WDM Driver Model, PNP and power management are very complex, with a maximum of 300 states, however, in the WDF driver model, the WDF framework implements the PNP and power management functions. Drivers can implement PNP and power management without writing a line of code. For example, it is inappropriate, the WDF driver framework is an abstraction of the WDM driver. It is like an abstract class in C ++. It implements PNP and power management in the form of pure virtual functions, if you do not have special requirements, simply use the power management and PNP management provided by the framework. To implement special functions, the Framework provides callback functions, which can be used to drive developers to implement callback functions. This callback function is like override in C ++, overwrite the virtual functions provided by the base class to implement your own functions;

4) WDF uses a queue-based I/O dispatch queue. The advantage is that you can specify the queues in which I/O is used, it reduces Io synchronization operations and system resource usage, such as lock occupation;

 

(2) After talking about the differences between the WDM Driver Model and the WDF driver model, Let's explain the WDM driver model. First, let's talk about the important data structure in the WDM Driver Model:

1) driver object (driver_object)

• Each driver has a unique driver object, which is loaded as an instance of the driver in the I/O manager of the kernel. • Typedef struct • {• pdevice_object deviceobject; • Implements hardwaredatabase; • Implements fastiodispatch; • Implements driverinit; • pdriver_startio driverstartio; • Implements driverunload; • pdriver_dispatch majorfunction [limit + 1] •} driver_object, * pdriver_object; • deviceobject: point to the device object created by the driver. When the driver calls iocreatedevice, it automatically assigns the correct device object pointer. Each driver has one or more Device objects. Each device object has a pointer pointing to the next driver object, and the last device object points to null. Here DeviceobjectThe first device object pointing to the driver object. Pass DeviceobjectTo traverse all the device objects in the drive object. • Majorfunction [irp_mj_num + 1]:Array of function pointers. Each Pointer Points to a function. This function is the dispatch function for processing IRP. For the driver, each driver has a unique driver object corresponding to it, and the driver object is loaded by the IO manager, another important data structure is the device object. The driver_object also contains a member of The deviceobject object. Generally, the DriverEntry of the driver calls iocreatedevice to create a device object, connect the device object with the driver object. Let's take a look at the data structure of the device object.

• 2) device object (device_object) • typedef struct _ device_object {•..... • struct _ driver_object * driverobject; • struct _ device_object * nextdevice; • struct _ device_object * attacheddevice ;•.... • pvoid deviceextension ;•..... •} device_object, * pdevice_object; • driverobject: pointing to the drive object in the driver; • nextdevice: pointing to the next device object, where the next device object is the same as the drive object, each device object forms a linked list based on the nextdevice domain to enumerate each device object. • attacheddevice: points to the next device object. When the driver is attached to this driver, the attacheddevice points to the higher driver. • Deviceextension: refers to the extended object of the device, that is, the struct defined by the programmer. Attacheddevice can be used to attach the upper-layer driver to the lower-layer driver. The deviceextension data structure is also a very important data structure. Generally, global information is stored, which facilitates management, for example, Synchronous lock management, and so on; increases the reusability of the driver. In the deviceextension structure, you can provide a pointer to the lower-layer device, so that you can find the lower-layer device from the upper-layer device, and you can also find the upper-layer device from the lower-layer device through attacheddevice. This makes it easy to find the device (3). After introducing the important data structure of the WDM Driver Model, let's take a look at how Windows applications communicate with the driver. For Windows platforms, applications communicate with drivers through APIS provided by windows, such as createfile, readfile, writefile, deviceiocontrol, and closefile. So how do these Apis relate to the driver? For example, createfile. When an application calls this function, it enters the kernel through the Registry to call ntcreatefile, then, the kernel uses the system's Io manager to create and send IRPs. For IRPs, the input and output request packages are all IRPs drivers. For Io management, PNP management, and power management, will be converted to the corresponding IRP and then forwarded to the driver. The main function of the relative driver is to implement the callback functions of these IRPs. In the WDF driver model, io works together with the IRP of the IO manager and the queue. This is explained in the differences between the WDM Driver Model and the WDF driver. Similarly, the process of readfile and writefile is similar to that of createfile, and is forwarded to the driver through IRP. (4) drivers are most concerned with I/O operations. In WDM and WDF drivers, the devices created by the driver generally have two read/write methods: 1) buffer mode; 2) direct mode; 3) Neither • buffer mode: Creates a buffer with the same user mode in the system kernel for sending or receiving hardware data, then copy the data in the buffer zone to the application. • direct mode: Unlike the buffer mode for reading and writing devices, the operating system will lock the buffer zone in user mode, then, the operating system maps the buffer address in kernel mode again. In this way, the user-mode buffer and the kernel-mode buffer point to the physical memory in the same region. The neither read/write method is not described here. For Windows driver development, the difficulty lies in reducing the copy of the buffer in the driver, because memcpy consumes a lot of time and CPU. (5) The IRP dispatch function is an important concept in the Windows Driver. The main function of the driver is to process I/O requests, most of the I/O requests are processed in dispatch letters.

• All the I/O requests to the driver in user mode are converted from the operating system to the IRP data structure. Different IRP data will be sent to different dispatch functions. • IRP definition: • in the Windows Kernel, there is a data structure called IRP (I/O Request package), that is, the input/output request package. It is an important data structure related to input and output. When the upper-layer application communicates with the underlying driver, the application sends an I/O Request, the operating system converts the I/O Request to the corresponding IRP data. Different types of IRPs are transmitted to different dispatch letters according to the type. (6) synchronous processing of drivers: similar to multi-threaded synchronization of Windows applications, the kernel also has synchronization mechanisms such as semaphores, mutex, spin locks, and events, the functions of these synchronization mechanisms Add a ke before the functions of the application. For example, for events, setevent for the kesetevent and waitforsingleobject corresponds to the kewaitforsingleobject. We know how to synchronize multiple threads in the application and how to synchronize the internal driver. If the driver and the application are synchronized, there is one way, call deviceiocontrol in the application to pass an event handle to the driver, lock the handle in the driver, and then call the kesetevent in the driver. In the application, you can use waitforsingleobject to synchronize the event. In fact, this operation also applies to the functions provided in DDK and wdk. The following describes the process of deviceiocontrol: deviceiocontrol is divided into two types: synchronous and asynchronous operations, mainly depending on the last parameter, this parameter can be used with a parameter in createfile to implement synchronous and asynchronous operations. For deviceiocontrol synchronization operations, when the application calls deviceiocontrol, there will actually be a waiting function, when the driver completes the corresponding IRP through iocompleterequest, it actually sends a signal to the application, the basic principle is similar to the above mentioned application and the driver synchronization. Similarly, it is similar when deviceiocontrol is called asynchronously. (7) There is a hierarchical concept in the driver. For example, the filter driver is very important in the NDIS driver. For example, if you want to implement a firewall or anti-virus software, the most reliable method is to implement an NDIS middle-layer driver. Under the multi-layer driver framework, RP requests are generally transmitted to the device object at the top layer of the device stack, you can directly end the IRP (iocompleterequest) or forward the IRP request to the lower-layer device object (iocalldriver). If you want to forward the IRP request to the lower-layer device object, when the IRP ends, the IRP will return along the back direction of the device stack. When you know that the underlying driver has completed the IRP request, you can choose to continue to IRP and send the IRP to the underlying device driver again. In this way, the firewall works as a filter driver to filter out malicious programs, otherwise it will be submitted to the driver. Anti-Virus Software is similar. In the kernel, the virus will be identified and killed! (8) PNP plug-and-play • The primary goal of the plug-and-play architecture is to automatically configure the device installation and removal without user intervention. • (1) the system can detect the insertion of new devices and the disconnection of devices. • (2) if the bus interface permits hot swapping, and ensure that the system can work normally, such as a USB device. when the device is inserted, the system will automatically load its drive, and ensure that other devices on the USB bus can work normally. In addition, when the system is running, unplugging a USB device does not cause a system crash. • Status transition diagram: • 1) when a device is added to the system, Windows looks for the correct driver and calls its DriverEntry routine; • 2) the PnP Manager then calls the adddevice routine of the driver and tells it to add a new device. In this case, the driver creates its own device object, that is, fdo. • 3) during processing, the driver receives the irp_mn_start_device IRP and starts a proper conversation with the hardware. • 4) if a device is to be pulled out, in Windows, irp_mn_remove is used to query driver devices. If the driver does not want the device to be deleted, it rejects the deletion request and sends irp_mn_cancel_remove IRP to bring it back to the starting state. • 5) if the user suddenly unblocks a device, in Windows, the irp_mn_supprise_remove IRP will be sent, and the driver must handle the interrupted transmission. (9) Power Management (omitted)