windows下的rootkit资料集合

Sharing Memory Between Drivers and Applications



2000 OSR Open Systems Resources, Inc.

Updated: 2002



At one time or another, most driver writers will have the need to share memory

between a driver and a user-mode program. And, as with most such things, there are a

wide variety of ways to accomplish the goal of sharing a block of memory between a

driver and a user-mode application. Some of these approaches are decidedly right and

maps that block of memory back in the address space of a specific user-

mode process, and returns the address to the application.



For the sake of brevity, we’ll restrict our discussion to these two, straightforward,

techniques. Other perfectly acceptable techniques include sharing a named section

that’s backed by either the paging file or a memory mapped file. Perhaps we’ll

discuss those in a future article. Also, note that this article won’t specifically address

sharing memory that’s resident on a device. While many of the concepts are the

same, sharing device memory with a user-mode program brings with it its own set of

special challenges.

Win32 function DeviceIoControl().



The only interesting decision for the driver writer who uses this method of buffer

sharing is which buffer method (or, “transfer type” as it’s known) to specify for the

IOCTL. Either METHOD_DIRECT (that is, using an MDL) or

METHOD_NEITHER (using user virtual addresses) will work. If

METHOD_DIRECT is used, the user buffer will be locked into memory. The driver

will also need to call MmGetSystemAddressForMdlSafe() to map the described

data buffer into kernel virtual address space. An advantage of this method is that the

driver can access the shared memory buffer from an arbitrary process context, and at

process. This is because access to the shared buffer is via the buffer’s user virtual

address. This will almost certainly mean that the driver must be at the top of the

device stack, called directly by the user application via the I/O Manager. There can be

no intermediate or file system drivers layered above the driver. Again practically

speaking, this probably also means that the driver is restricted to accessing the user

buffer from within its dispatch routines, when called by the requesting process.



Another important restriction inherent in using METHOD_NEITHER is that access

by the driver to the user buffer must always be done at IRQL PASSIVE_LEVEL.

This is because the I/O manager hasn’t locked the user buffer in memory, and it could

for example, due to quota limitations. Additionally, user applications cannot allocate

physically contiguous or non-cached memory. Still, if all a driver and a user mode

application need to do is pass data back and forth using a reasonably-sized data buffer,

this technique can be both easy and useful.



As easy as it is, using IOCTLs to share memory between a driver and a user-mode

application is also one of the most frequently misused schemes. One common

mistake new NT driver writers make when using this scheme is that they complete the

IOCTL sent by the application after having retrieved the buffer address from it. This

is a very bad thing. Why? What happens if the user application suddenly exits, for

generally to be avoided.



Mapping Kernel Memory To User Mode

That leaves us with the second scheme mentioned above: Mapping a buffer allocated

in kernel mode into the user virtual address space of a specified process. This scheme

is surprising easy, uses API familiar to most NT driver writers, and yet allows the

driver to retain maximum control of the type of memory being allocated.