卷的文件系统识别、卷的挂载以及路径解析


2011-10-25

前段时间琢磨文件过滤驱动的时候碰到一个棘手的问题,当时挂上wrk内核分析,发现了问题的关键点。分析的过程中明显感觉自己对IoMgr、ObjMgr、Fsd、Volume这些组件的结构关系掌握得很烂,于是最近这几天专门又挂上wrk内核,一点一点的追踪。有了一点收获,记录在这里,备忘。顺便也许会给一些朋友一点点帮助。

卷的创建

FtDisk.sys(或Disk.sys)调用FtpCreateNewDevice(或DiskCreateFdo)为卷创建FDO。
该函数会调用IoCreateDevice来创建DO,即卷的FDO。IoCreateDevice创建完毕DO后,会调用ObInsertObject将FDO挂入ObjMgr的空间,就是咱们用WinObj或WinObjEx看到的那个树形组织。
总结来说,调用关系如下:

FtpCreateNewDevice
    |- IoCreateDevice
        |- ObCreateObject
            |- ObInsertObject

这个过程完毕后,WinObj中 \Device\HarddiskVolumeX 的节点就“指向”了上面过程中创建的 FDO(后面称之为DiskVolumeFDO)。 注:Disk.sys是开源的,源码在wdk中。FtDisk没有源码,所以我调试的时候主要是参考的Disk.sys源码和IoCreateDevice的调用栈。

卷的挂载

系统初始化时,为了节省不必要的资源损耗,并不会将所有的文件系统(后简称fsd)都加载。而是另外提供一个功能模块Fs_rec.sys来根据具体的卷来加载必须的fsd。具体的过程如下:

Fs_rec.sys在初始化时,会声明几个MS支持的fsd类型的伪对象,比如fat、ntfs、cdfs、udfs。并通过调用IoRegisterFileSystem来把这几个伪对象挂入一个全局队列(请参考这个函数的源码),这个队列里保存着系统中所有的文件系统的CDO。而实际上在Fs_rec初始化的这个阶段,这个全局队列里实际里保存的都是Fs_rec创建的伪对象。这样做的目的是什么呢,咱们继续往下看。
当系统需要访问某个卷中的文件或目录等数据时,如果发现该卷没有挂载任何Fsd,就会调用IopMountVolume来挂载对应的Fsd(可参考wrk源码中的IopCheckVpbMounted函数)。这个函数会遍历之前提到的那个全局队列中的所有结点,挨个给链表中的结点包含的对象的发送IRP_MJ_FILE_SYSTEM_CONTROL.IRP_MN_MOUNT_VOLUME请求。
而前面咱们提到,这个时候队列里的全是伪对象,这些伪对象的Driver_object是Fs_rec.sys。于是Fs_rec这个时候会接收并处理这个IRP_MJ_FILE_SYSTEM_CONTROL请求,并针对具体的伪对象,比如fat的伪对象,来判断需要挂载的卷是否是fat卷。如果不是,则返回失败。如果是,那么Fs_rec就会把FastFat.sys加载到系统中,然后Fs_rec自身返回失败。而FastFat在初始化过程中,又会调用IoRegisterFileSystem把自己的CDO挂入那个全局链表(请参看fastfat源码中的fatinit.c中的DriverEntry函数)。这个时候全局链表就存在真正的fsd的CDO。而因为之前Fs_rec自身返回了失败,于是IopMountVolume会接着遍历全局链表,于是就会发现真正的fastfat的CDO,这个时候再发送IRP_MJ_FILE_SYSTEM_CONTROL.IRP_MN_MOUNT_VOLUME请求,接收到的返回值就是成功了。因为FastFat确实会真正的完成了整个卷的挂载过程。

总结一下:

最初,全局链表中只有Fs_rec创建的伪对象,这些伪对象负责把对应的fsd加载到系统,并返回错误,推动整个链表的遍历,直到真正的fsd完成卷的挂载,才会返回成功,结束遍历。 最初在梳理框架的时候参考的是《windows internals》,里面是这么描述的:

“After loading a file system driver, File System Recognizer forwards the mount IRP to the driver and lets the file system driver claim ownership of the volume.”[/quote]而实际上如我之前的描述,fs_rec只是负责把fsd加载到系统,并没把挂载请求发送给fsd。而是IopMountVolume发送这个请求。我们可以进一步看下调用栈,采用的是win2003的虚拟系统:

f78de190 808ed241 84a32340 84db4000 00000000 Fastfat!DriverEntry
f78de260 808ed355 800002a0 00000001 00000000 nt!IopLoadDriver+0x687
f78de288 80991a9b 800002a0 f78de310 f78de38c nt!IopLoadUnloadDriver+0x43
f78de304 8088284c f78de394 f78de39c 8082c605 nt!NtLoadDriver+0x143
f78de304 8082c605 f78de394 f78de39c 8082c605 nt!KiFastCallEntry+0xfc
f78de380 f779b15b f78de394 80a45be4 84685f08 nt!ZwLoadDriver+0x11
f78de39c f779b9b3 c000010e f779b906 80a45be4 Fs_Rec!FsRecLoadFileSystem+0x4f
f78de3c4 f779b0b0 84685f08 85836f68 84685f08 Fs_Rec!FatRecFsControl+0x35
f78de3d4 809ab1d2 84685f08 85836f68 84685f08 Fs_Rec!FsRecFsControl+0x6c
f78de404 8081f881 808ed918 f78de43c 808ed918 nt!IovCallDriver+0x110
f78de410 808ed918 84f1e8d0 8089f540 85046ea0 nt!IofCallDriver+0x11
f78de43c 808edc0c 84685f08 80a46150 85046ea0 nt!IopLoadFileSystemDriver+0x60
f78de490 80822ffc c000019c 84a5b800 00000000 nt!IopMountVolume+0x2ca

上面是fsd的加载过程,可见,是由Fs_rec来完成的。再看看卷挂载的调用栈:

f78de254 b94eec7f 844d45d0 84b4c948 84b9af00 Fastfat!FatMountVolume
f78de274 b94eed28 844d45d0 858aae70 4ec07aef Fastfat!FatCommonFileSystemControl+0x3f
f78de2c0 809ab1d2 84772e20 858aae70 858aafb0 Fastfat!FatFsdFileSystemControl+0x82
f78de2f0 8081f881 f732d23e f78de370 f732d23e nt!IovCallDriver+0x110
f78de2fc f732d23e 84df2bd0 858aae70 00000000 nt!IofCallDriver+0x11
f78de370 f732d616 84df2bd0 858aae70 80a45be4 fltMgr!FltpFsControlMountVolume+0x186
f78de3a0 809ab1d2 84df2bd0 858aae70 858aafd4 fltMgr!FltpFsControl+0x5a
f78de3d0 8081f881 f74ef27c f78de404 f74ef27c nt!IovCallDriver+0x110
f78de3dc f74ef27c 80a45be4 84917210 00000000 nt!IofCallDriver+0x11
f78de404 809ab1d2 84917210 858aae70 84f1e8d0 Dfs!DfsFilterFsControl+0x82
f78de434 8081f881 808edaf4 f78de490 808edaf4 nt!IovCallDriver+0x110
f78de440 808edaf4 80a46150 85046ea0 80a461d0 nt!IofCallDriver+0x11
f78de490 80822ffc 84917210 84a5b800 00000000 nt!IopMountVolume+0x1b2

OK,整个框架说完了,咱们来细说fsd的挂载过程, Fsd会在自己的IRP_MJ_FILE_SYSTEM_CONTROL.IRP_MN_MOUNT_VOLUME响应函数里会为这个待挂载的卷创建一个FsdVolumeFDO(可参考fastfat源码中fsctrl.c中的FatMountVolume函数)。并对DiskVolumeFDO->vpb进行设置,使

DiskVolumeFDO->vpb->DeviceObject = FsdVolumeFDO,
DiskVolumeFDO->vpb->RealDevice = DiskVolumeFDO。

到这里,卷和Fsd就通过vpb建立了连接,而Fsd也通过FsdVolumeFDO向系统声明了自己负责这个卷进行解析、管理。

这样,挂载之后,所有这个卷上的数据请求,比如文件、目录的打开、删除、读写,都会被转交给FsdVolumeFDO,最后由Fsd进行处理。具体的转交过程在后面描述。

卷中文件、目录的路径解析

现在咱们来说说系统访问具体某个文件时,系统的解析过程。以访问\??\c:\windows\boxcounter.dll这个文件为例。
当ObjMgr接收到这个访问请求时,会在它的名空间里对这个路径进行解析,在解析的过程中它发现\??\c:实际指向\Device\HarddiskVolume0,这是一个Device,指向DiskVolumeFDO,它提供了路径解析函数IopParseDevice(保存在object_header->Type->TypeInfo->ParseProcedure中)。
ObjMgr使用IopParseDevice继续对剩余路径\windows\boxcounter.dll进行解析,最后导致ObjMgr发送一个打开请求给Fsd(没有上层文件过滤驱动的情况下),发送的方式可能有两种:

但是咱们在回顾下,对于整个路径解析过程,ObjMgr只在自己的名空间里找到了DiskVolumeFDO,并没有找到具体的fsd。那么它是如何把请求交给fsd的呢。答案就是2中提到的vpb。ObjMgr通过DiskVolumeFDO->vpb->DeviceObject找到了FsdVolumeFDO,然后把请求发到这个FDO上,最后Fsd接收到这个请求,完成了剩余的解析过程。

在分析过程中,我很奇怪为什么MS没有把FSD和Disk驱动做成一个设备栈,想来想去没有想出什么很出众的解释。于是请教sinister师傅,得到这样的解释,附在这里:

嘿黑 11:06:17
贾佳师傅,有个问题请教:
MS为什么不把FSD和磁盘驱动堆叠成一个设备栈,而要用vpb来链接两者。有什么原因吗?或者说有什么历史原因?

sinister 9:26:48
我觉得是设计的考虑,因为FSD层单独出来,也是一个区域的划分,比如网络层的TDI驱动,其实就是个FSD的应用。这种设计符合MS的CLIENT/SERVER 的设计模型,因为封装且又不开源的原因,只要上层要数据下层返回就行。这样不必关心下面的细节。又能留出接口。像LINUX这种开源的设计,这种实现就基本上 FS与BLOCK(磁盘设备)层之间没有什么明显的划分了。都是通过一个结构制过去就行了。连设备栈这种东西都没有。 [/quote]

参考资料:

  1. wrk内核
  2. 《windows internals》(第四版、第五版)
  3. 《Windows内核情景分析-采用开源代码ReactOS》
  4. FastFat源码
  5. “关于文件系统和磁盘驱动的一点学习心得”- weolar
  6. “Inside WINDOWS NT Object Manager” - gloomy
  7. disk.sys源码