探究Windows 2000/XP原型PTE(http://webcrazy.yeah.net)

最新推荐文章于 2022-06-17 10:57:21 发布

freexploit

最新推荐文章于 2022-06-17 10:57:21 发布

阅读量2k

点赞数

分类专栏：编程指南文章标签： windows object c 算法 query 磁盘

本文链接：https://blog.csdn.net/freexploit/article/details/275474

版权

本文详细探讨了Windows 2000/XP操作系统的内存管理，尤其是原型PTE（Prototype PTE）的角色。通过原型PTE，系统能够有效地处理内存共享，特别是对于文件映射的情况。当多个进程需要访问同一文件时，Windows 2000/XP使用Section对象和PPTE表来实现共享，并避免频繁更新硬件PTE。在Page Fault处理过程中，通过软件模拟来处理指向PPTE的无效PTE，从而提高效率。文章还介绍了如何通过软中断和调试工具验证这一机制。

摘要由CSDN通过智能技术生成

探究Windows 2000/XP原型PTE
              WebCrazy(http://webcrazy.yeah.net)

    内存管理可以说是操作系统实现中最重要的环节，也是最为复杂的一环节。对于相对贫乏的内存资源，内存共享也成了一个很重要的有效手段。Windows 2000/XP在此方面的实现借助于一个称为原型PTE(Prototype PTE，PPTE)的软件机制。在《小议Windows NT/2000分页机制》中我详细的介绍了Intel X86实现分段、分页的硬件PTE工作方式。我们来回顾一下这种机制：

    假设我们的一个进程映射了从虚拟地址0xXXXXXXXX(假设位于分配粒度上)开始的4M空间，而这4M空间当前都相应的映射了实际的物理内存(鉴于Lazy evaluation等的先进思想，这种情况在Windows 2000/XP中比较少见)。我们将这4M空间分成1000块的4K(PAGE_SIZE，X86处理器决定)，对于第n个4K(0<=n<1000)，其虚拟地址(0xXXXXXXXX+n*4K)，我们都有一个对应的硬件PTE，指出目前这4K驻留于物理内存的位置。通过由PDBR(CR3寄存器)与虚拟地址可定位这个硬件PTE(具体请参阅《小议Windows NT/2000分页机制》)。

    现在让我们来考虑这样一种情况，我们有一个文件其大小也为4M，我们知道通常我们要使用这个文件都要将它读入内存。试想同时有两个或更多的进程需读写这个文件，这就需要解决内存共享的问题。实际上就算当前只有一个进程访问这个文件，对于这种潜在的需要共享的文件，Windows 2000/XP均会事先考虑共享情况。她通过一个称为Section的内核对象来实现这样的目的。仔细想想，这种情况下内存共享决不仅仅是内存资源的充分利用，就算我们可以为每个进程各分配4M空间，但是这将导致各个进程某种时刻可能得不到这个文件的最新内容。这是非常糟糕的情况。在内部Windows 2000/XP利用原型PTE来解决这样的情况。基于硬件PTE相同的原理，对于这样一个4M的文件，在映射这个文件时，Windows 2000/XP同样的将这个文件分成1000块，每块4K(PAGE_SIZE)大小。然后从页交换区分配1000个DWORD，每个DWORD值都是原型PTE，它们组成原型PTE表。对于这个文件的第n个4K(0<=n<1000)，如果当前其驻留在物理内存中的话，其对应的PPTE的Valid位(bit 0，与硬件PTE一致)为1，然后这个PPTE的Page Frame Number(PPTE的高20位)用于指示物理内存。如果当前其仍然在磁盘中的话，Valid位为0。针对这种情况，通过PPTE的高20位(PFN Entry)，查找Page Frame Datbase(由MmPfnDatabase定位)，通过PFN Entry的Subsection PTE(windbg中称为restore pte,《Inside Windows 2000》中称为original pte，Windows XP内部称为Subsection PTE)，定位Subsection，然后通过Subsection指向的Control Area的FILE_OBJECT，与PPTE在PPTE表的偏移n，通过公式：

    PFN Entry Subsection PTE->Subs