《NDIS驱动框架探究.doc》由会员分享，可在线阅读，更多相关《NDIS驱动框架探究.doc（12页珍藏版）》请在金锄头文库上搜索。
1、 NDIS驱动框架探究By AntBeanFearless，Passion， Endure在我看来NDIS驱动有几个难点：1.框架难，NDIS驱动的整体框架跟接触的文件过滤驱动很不一样，你需要考虑的比较多，整个框架的堆叠不再是向文件过滤驱动那样，使用AttachDevice堆叠设备，然后IoCallDriver传递请求；2.硬件操作的敏感性，网卡设备的热插拔，电源状态的变化都会影响到驱动程序；3.系统资源使用的敏感性，NDIS驱动本身是要收包 发包，网络包的数据量是非常大的，如果在分配网络封包时没有及时释放，很有可能导致系统资源不足。本篇文章主要对NDIS驱动框架进行探究。在介绍内容之前，先说
2、明一些概念。1. 面向连接的网络和无连接的网络 与 面向连接的协议和无连接的协议 面向连接的网络是指通过电路交换进行的局域网。一台机器如果需要给另外一台机器发送信息，就需要先像打电话一样呼叫另外一台机器，另外一台机器可以接受或者拒绝。一旦接受，就会使用一个专用的线路维持该连接。该连接的容量是固定的，而且只归该连接所有。这种局域网最典型的例子是ATM网络。 无连接的网络是指通过分组交换传输信息的局域网。一台机器如果给另外一台机器发送信息，需要传输的数据组织成一个分组，发送出去。所有正在通信的计算机共用一个连接。典型的例子是以太网和FDDI。(参见用TCP/IP进行网际互联 第四版第一卷 第二章
3、底层网络技术回顾) 以上的面向连接和无连接针对的是物理上的网络硬件，属于OSI七层模型中的物理层；而面向连接的协议和无连接的协议则是针对协议的，与硬件是无关的，属于协议层。常见的面向连接的协议有TCP协议，无连接的协议有UDP协议。2. 电源状态 D0 D1 D2 D3 ACPI规定，设备处于四种状态之一，D0到D3。D0是完全打开，D3是完全关闭。D1和D2由驱动程序自己定义。（参见深入解析windows操作系统 第四版 第九章 第五小节 电源管理器）3. 序列化NDIS驱动和非序列化NDIS驱动 对NDIS驱动的请求不再是IRP的形式，而是Packet的形式。其他驱动例如TDI驱动通过ND
4、IS库函数如NdisSend向NDIS驱动发送请求，事实上NDIS库会对Packet进行排队，保证对NDIS驱动的调用是串行的，一个Packet处理完才会发送另一个Packet给NDIS驱动。这样的NDIS驱动就叫做序列化的NDIS驱动。 而一个非序列化的NDIS驱动则是指，NDIS库不负责对Packet进行排队和串行化，需要NDIS驱动自己处理同时多个Packet请求的情形。排队和管理多个并发请求的任务落到了NDIS驱动程序的头上。 （参见深入解析windows操作系统 第四版 第十三章 第六小节 NDIS驱动程序）NDIS驱动本身分为两种，Protocol Driver和Miniport
5、Driver。至于NDIS中间层驱动，则是由前两种演化而来。Miniport Driver用来驱动网卡，Protocol Driver是协议驱动，负责将要发送的数据组装成符合特定Protocol的网络封包然后调用Miniport Driver提供的发送功能完成发送。也就是说，Protocol Driver和Miniport Driver具有实质意义上的堆叠关系。Protocol Driver负责网络数据的封包，以及封包的解析获得；而Miniport Driver负责提供物理硬件上的驱动，保证数据包能够正常收发，并通知上层的Protocol Driver。Miniport Driver和Prot
6、ocol Driver并不是通过普通意义上的IoAttachDevice进行叠加的。而是通过NDIS库进行粘合的。NDIS库要求Miniport Driver和Protocol Driver各自提供符合NDIS要求的接口，供NDIS库在运行时调用。这个过程类似于C+中的虚函数。NDIS库要求这Protocol Driver和Miniport Driver各自实现自己那个类的虚函数，而NDIS库自己则是直接调用这些虚函数去完成操作。下面照样是用具体的代码说事儿。我将使用ReactOS上面的代码来分析NDIS驱动和NDIS库之间的关系。当然，主要参考了毛德操老师的windows内核情景分析和Rea
7、ctOS 0.3.1的代码。下面如无特殊说明，windows内核均指ReactOS的代码，代码均摘自ReactOS 0.3.1。必须先声明的是，我不会试图去分析NDIS驱动框架的各个方面。我将只针对NDIS驱动的初始化和NDIS驱动接收包 发送包的流程来说明NDIS库和NDIS驱动的关系。NDIS驱动初始化过程探究1、 miniport driver初始化过程 以下代码来自ReactOS提供的NE2000网卡驱动模块。这是一个典型的实际的miniport驱动。为何没有使用先前分析的NDISWDM那个miniport驱动进行框架分析，是因为那是一个虚拟网卡的驱动。这里采用实际的物理NIC驱动进行
8、分析。(ReactOS -0.3.1DriversNetworkDDNe2000Main.c DriverEntry函数）这是我们常见的minport驱动的开头。把CHARACTERSISTICS中的各个函数指针赋值，然后Register一下。从ddk中我们很容易就知道MiniportInitialize作为初始化函数会被调用，但事实上，你知道，即使到DriverEntry的末尾，也没有调用CHARATERISTICS中的任意一个函数。那问题就是，Miniport的初始化函数到底是何时在哪儿被调用的？好了，面对这个暂时无解的问题，我们唯一的解决方案就是弄清楚NDIS库到底在背后做了些啥我们不知
9、道的事情。第一反应阅读NDIS库的NdisMRegisterMiniport函数。刚才我们看到的是一个别人写的miniport驱动的代码，下面我们就会切换到windows内核当中，查看它里面的NDIS库到底做了啥。DriversnetworkndisndisMiniport.c 函数NdisMRegisterMiniport可以看到，这里先是从传入的NdisWrapperHandle中获得PNDIS_M_DRIVER_BLOCK 然后给该BLOCK的CHARACTERISTICS赋值。这些都比较简单。最重要的是，设置了该BLOCK中的DriverObject的MajorFunction的IRP
10、_MJ_PNP和AddDevice函数。现在我们来看看，这个唯一支持的IRP_MJ_PNP干啥了。 在该函数中，调用了十分可疑的NdisIPnpStartDevice。继续跟踪该函数。我相信你已经看到了那个指针的调用。这里情况就很明白了，操作系统调用完DriverEntry后，发送了一个IRP_MJ_PNP的请求，启动miniport设备并调用了miniport的InitializeHandler。NDIS库所做的就是在注册时默默的为miniport驱动提供了一个IRP_MJ_PNP的操作函数，并默默地调用注册的Characteristics的InitializeHandler。2、proto
11、col driver初始化过程这里使用ReactOS中提供的协议驱动局域网lan的代码。driversnetworklanlanLan.cDriverEntry中调用了LANRegisterProtocol，下面直接看LANRegisterProtocol同样，也是准备一个Charateristics，然后注册，也是没有看到其中哪个函数的调用。这回你应该清楚了，我们需要看看NDIS库的NdisRegisterProtocol到底干啥了。driversnetworkndisndisProtocol.c 函数NdisRegisterProtocol该函数中有个For循环，针对从注册表读到的值调用该
12、循环，你仔细看看该循环就会懂得。该循环中，有个地方你没看错，那就是BindHandler的调用。在NdisRegisterProtocol中，针对已经存在的每个miniport，调用了注册的BindHandler。这就是NDIS库为我们做的。现在，我想你应该已经明白，如果要看Miniport Driver的初始化过程，你应该先读了DriverEntry，然后去读InitializeHandler函数；而如果你要看Protocol Driver的初始化过程，你应该先读了DriverEntry，然后去读BindHandler函数。这才是完整的初始化过程。NDIS驱动收包过程探究收包的触发过程，想想
13、也知道首先是网卡收到包后产生一个中断，然后触发上层读取该包。下面我们将联系刚才的那个miniport driver来看整个过程是怎样在miniport driver和protocol driver中流动的。在以上miniport driver的初始化过程中一节看到的DriverEntry函数指定了该NIC的中断延迟处理函数为MiniportHandleInterrupt。下面读该函数。该函数中根据中断的类型，调用了HandleReceive函数。HandleRecevie中调用了NICReadPacket，而NICReadPacket又调用了NICIndicatePacket，NICIndic
14、atePacket中又调用了NdisMEthIndicateReceive。到此为止，我们先分清一下虚实。这个NdisMEthIndicateReceive是由NDIS库提供的函数。表示一个以太网封包到了。显然，我们写的以太网网卡的miniport driver的任务已经完成了。它在自己的中断延迟处理函数中读取了该Packet，并调用了NdisMEthIndicateReceive通知上层说收到网络封包了。问题就变成了，当miniport driver调用了NdisMEthIndicateReceive进行通知时，NDIS库到底做了啥，让上层读取该封包的？现在看NdisMEthIndicate
15、Receive。这是一个宏，指向的是PNDIS_MINIPORT_BLOCK中的EthRxIndicateHandler指针。该函数指针到底指向哪个函数呢？前面其实我们已经在NdisIPNPStartDevice中见到过。好吧，你别晕，虽然我也有点晕。返回去看看，其实指向的是EthFilterDprIndicateReceive()。再看看该函数干嘛了。其实也就是调用MiniIndicateData。下面看MiniIndicateData。好吧，你看到了吧，调用了AdapterBinding的ProtocolBinding的ReceiveHandler了！顺利会师！整个过程就是：1. 我们的miniport driver在延迟中断处理函数中调用了Ndis库的NdisMEthIndicateReceive2. NDIS库的NdisMEthIndicateReceive调用每一个绑定到该miniport的protocol的 ReceiveHandler3. 顺利会师！NDIS驱动发包过程探究NDIS驱动的发包过程显然是由上层触发的，上层调用某些发送
