handling IRPs 12: Data Transfer Mechanisms

Data Transfer Mechanisms

The Windows family of operating systems supports three data transfer mechanisms:

·         Buffered I/O operates on a kernel-mode copy of the user’s data.

·         Direct I/O directly accesses the user’s data through Memory Descriptor Lists (MDLs) and kernel-mode pointers.

·         Method neither I/O (neither buffered nor direct I/O) accesses the user’s data through user-mode pointers.

 

For standard I/O requests, such as IRP_MJ_READ and IRP_MJ_WRITE, drivers specify which transfer mechanism they support by modifying the value of theDeviceObject->Flags field soon after creating the device.

Buffered I/O

To receive read and write requests as buffered I/O, the driver sets the DO_BUFFERED_IO flag in theDeviceObject->Flags field during initialization. When a driver receives a buffered I/O request, theIrp‑>AssociatedIrp.SystemBuffer field contains the address of the kernel-mode buffer on which the driver should operate. The I/O Manager copies data from the kernel-mode buffer to the user-mode buffer during a read request, or from the user-mode buffer to the kernel-mode buffer during a write request.

Direct I/O

To receive read and write requests as direct I/O, the driver sets the DO_DIRECT_IO flag in theDeviceObject->Flags field during initialization. When a driver receives a direct I/O request, theIrp->MdlAddress field contains the address of an MDL that describes the request buffer. The MDL lists the buffer’s virtual address and size, along with the physical pages in the buffer. The I/O Manager locks these physical pages before issuing the request to the driver and unlocks them during completion. The driver must not use the user-mode buffer address specified in the MDL; instead, it must get a kernel-mode address by calling theMmGetSystemAddressForMdlSafe macro.

Neither Buffered nor Direct I/O

To receive neither buffered nor direct I/O requests, the driver sets neither the DO_BUFFERED_IO flag nor the DO_DIRECT_IO flag in theDeviceObject‑>Flags field. When a driver receives such a request, theIrp‑>UserBuffer field contains the address of the data pertaining to the request. Because this buffer is in the user address space, the driver must validate the address before using it. To validate the pointer, a driver calls theProbeForRead or ProbeForWrite function within atry/except block. The driver must also perform all access to the buffer within atry/except block.

In addition, the driver must copy the data to a safe kernel-mode address in the pool or on the stack before manipulating it. Copying the data to a kernel-mode buffer ensures that the user-mode caller cannot change the data after the driver has validated it.

Note: For detailed information on probing and on problems commonly seen in driver I/O paths, see the white paper “Common Driver Reliability Issues.”