分配并且映射页：
现在剩下了前面提到的第二种方法：分配内存页并且映射这些页到特定进程的用户虚拟地址空间上。使用大多数Windows驱动编写者常见的API，这个方法令人惊讶的容易，同时也允许驱动对分配内存的类型具有最大的控制能力。
驱动无论使用什么标准方法，都是希望分配内存来共享。例如，如果驱动需要一个适当的设备（逻辑）地址作DMA，就像内存块的内核虚拟地址，它能够使用 AllocateCommonBuffer来分配内存。如果没有要求特定的内存特性，要被共享的内存大小也是适度的，驱动可以将0填充、非分页物理内存页分配给Buffer。
从主内存分配0填充、非分页的页面，使用MmAllocatePagesForMDL或者MmAllocatePagesForMdlEx。这些函数返回一个MDL描述内存的分配。驱动使用函数MmGetSystemAddressForMdlSafe映射MDL描述的页到内核虚拟地址空间。从主内存分配页比使用分页内存池或者非分页内存池得到的内存更加安全，后者不是一个好主意。
PS：这种方式是内核来分配内存空间，但是是使用MmAllocatePagesForMDL从主内存池中分配，返回得到一个MDL，对于驱动如何使用该共享内存，采用MmGetSystemAddressForMdlSafe得到其内核地址。对于应用层使用该共享内存，采用 MmMapLockedPagesSpecifyCache映射到应用层进程地址空间中，返回用户层地址空间的起始地址，将其放在IOCTL中返回给用户应用程序。
借助一个用来描述共享内存的MDL，驱动现在准备映射这些页到用户进程地址空间。这可以使用函数MmMapLockedPagesSpecifyCache来实现。你需要知道调用这个函数的窍门是：
你必须在你希望映射Buffer的进程上下文中调用这个函数。
PS：如果是在别的进程上下文中调用，就变成了映射到其他进程上下文中了，但是我如何保证在我希望映射Buffer的进程上下文调用呢？
设定AccessMode参数为UserMode。对MmMapLockedPagesSpecifyCache函数调用返回值是MDL描述内存页映射的用户虚拟地址空间地址。驱动可以将其放在对应IOCTL的缓存中给用户应用程序 。
你需要有一个方法，在不需要时将分配的内存清除掉。换句话说，你需要调用MmFreePageFromMdl来释放内存页。并且调用IoFreeMdl来释放由MmAllocatePageForMdl(Ex)创建的MDL。你几乎都是在你驱动的IRP_MJ_CLEANUP处理例程（WDM）或者 EvtFileCleanup事件处理回调（KMDF中作这个工作）。
这是所要做的，综合起来，完成这个过程的代码见下面。
代码PVOID CreateAndMapMemory(OUT PMDL* PMemMdl,
OUT PVOID* UserVa)
{
PMDL Mdl;
PVOID UserVAToReturn;
PHYSICAL_ADDRESS LowAddress;
PHYSICAL_ADDRESS HighAddress;
SIZE_T TotalBytes;
// 初始化MmAllocatePagesForMdl需要的Physical Address
LowAddress.QuadPart = 0;
MAX_MEM(HighAddress.QuardPart);
TotalBytes.QuadPart = PAGE_SIZE;
// 分配4K的共享缓冲区
Mdl = MmAllocatePagesForMdl(LowAddress,
HighAddress,
LowAddress,
TotalBytes);
if(!Mdl)
{
Return STATUS_INSUFFICIENT_RESOURCES;
}
// 映射共享缓冲区到用户地址空间
UserVAToReturn = MmMapLockedPagesSpecifyCache(Mdl,
UserMode,
MmCached,
NULL,
FALSE,
NormalPagePriority);
if(!UserVAToReturn)
{
MmFreePagesFromMdl(Mdl);
IoFreeMdl(Mdl);
Return STATUS_INSUFFICIENT_RESOURCE;
}
// 返回，得到MDL和用户层的虚拟地址
*UserVa = UserVAToReturn;
*PMemMdl = Mdl;
return STATUS_SUCCESS;
}
当然，这种方法也有缺点，调用MmMapLockedPagesSpecifyCache必须在你希望内存页被映射的进程上下文来做。较之使用 METHOD_NEITHER的IOCTL方法，该方法表现出不必其更多的灵活性。然而，不像前者，后者只需一个函数（MmMapLockerPagesSpecifyCache）在目标上下文被调用。由于很多OEM设备驱动在设备栈中只有一个且直接基于总线的（也就是在其上没有别的设备，除了总线驱动其下没有别的驱动），这个条件很容易满足。对于那些少量的设备驱动，处于设备栈的深处并且需要和用户模式应用直接共享 Buffer的，一个企业级的驱动编写者可能能找到一个安全的地方在请求的进程上下文中调用。
在页面被映射以后，共享内存就可以象使用METHOD_XXX_DIRECT的IOCTL方法一样，能够在任意的进程上下文被存取，也可以在高IRQL上存取（因为共享内存来之非分页内存）。
PS：需要我们确定的一点就是何时调用MmMapLockedPagesSpecifyCache安全的映射到指定进程的上下文中。还有一点，就是该共享内存处于非分页内存中，所以可以在搞IRQL上存取。
如果你使用这种方法，有一个决定性的事情一直要记者：你必须确信你的驱动要提供方法，在任何时候用户进程退出的时候，能够将你映射到用户空间的页面作取消映射的操作。这件事情的失败会导致系统在应用层退出的时候崩溃。我们找到一个简单方法就是无论何时应用层关闭设备句柄，则对这些页面作取消映射操作。由于应用层关闭句柄，出现意外或者其他情况，驱动将收到对应于该应用层打开的设备文件对象的一个IRP_MJ_CLEANUP，你可以确信这是工作的。你将在 CLEANUP使执行这些操作，而不是CLOSE，因为你可以保证在请求线程的上下文中得到Cleanup IRP。下面代码可以看见分配资源的释放。
代码VOID UnMapAndFreeMemory(PMDL PMdl,PVOID UserVa)
{
if(!PMdl)
{ return ;}
// 解除映射
MmUnMapLockerPages(UserVa,PMdl);
// 释放MDL锁定的物理页
MmFreePagesFromMdl(PMdl);
// 释放MDL
IoFreeMdl(PMdl);
}
其他挑战：
无论使用哪种机制，驱动和应用程序将需要支持同步存取共享内存的通用方式，这可以通过很多许多方法来做。可能最简单的机制是共享一个或者多个命名事件。应用和驱动共享事件的最简单方法就是应用层生成事件，然后将事件句柄传递给驱动层。驱动然后从应用层的上下文中Reference事件句柄。如果你使用这种方法，请不要忘记在驱动的Cleanup处理代码中Dereference这个句柄。
PS：一定要注意解引用来自应用层的事件对象。
总结：
我们观察了两种在驱动和用户模式应用程序共享内存的方法：
1、用户层创建缓冲区并且通过IOCTL传递给驱动
2、在驱动中使用MmAllocatePagesForMdl分配内存页，得到MDL，然后将该MDL所描述的内存映射到用户层地址空间（MmMapLockedPagesSpecifyCache）。得到用户地址空间的起始地址，并通过IOCTL返回给用户层。
译者注：
在使用命名事件来同步驱动和应用程序共享缓冲区时，一般不要使用驱动程序创建命名事件，然后根据应用程序名称打开的方法。这种方法虽然可以使得驱动激活事件后，所有相关应用程序都能够被唤醒，方便程序的开发，但是他有两个问题：一是命名事件只有在WIN32子系统起来后才能正确创建，这会影响到驱动程序开发。最严重的问题是在驱动中创建的事件其存取权限要求比较高，在WinXP下要求具有Administrator组权限的用户创建的应用程序才能够存取该事件。在Vista系统下由于安全功能的强化，这方面的问题更加严重。因此尽量使用应用程序创建的事件，或者通过其他同步方式。
转载自：http://hi.baidu.com/clingingice/blog/item/abeabc1016bd13c1a7ef3ff6.html
英文原文：http://www.osronline.com/article.cfm?article=39