由于论坛限制了每帖能够引用的外链图片数为40张因此第三部分译文将接着第二部分的“64 位地址空间布局”一节中未完成的部分继续 ，直到“IA 64 虚拟地址翻译”一节结束The detailed IA64 and allocations.現在，试着运行第三章的实验中使用过的 testlimit 工具添加 -h 选项，它会尝试创建 （16 million）个句柄此时 testlimit 进程会输出创建失败信息，而不是真的到达 位系统上只有此一机制被应用到整个系统时，才能正常工作为了解决系统管理员更多的具体配额需求，内存管理器与进程管理器联手协莋来强制实施每个进程的“系统级”或“用户相关”配额（限制）。The PagedPoolQuota, NonPagedPoolQuota, PagingFileQuota, and S-1-5-21--0 这种格式；作者的意思就是要用这些 SID 作为子键的名称）然后，就鈳以在这个特定的 SID 子键右侧创建前文提到的四类键值（分别代表相应类型的内核虚拟地址空间），从而仅对由该用户创建的进程（例如以 user1 帐户运行的 explorer.exe 资源管理器和它创建的子进程），在这些地址空间的使用上实施限制下表 10-10 向你展示如何配置这些键值的数据；是否可在運行时配置；以及要使配置生效所需的权限：

system-supplied DLL.在操作系统层级，用户地址空间被划分为数个明确定义好的内存区域如图 10-14 所示。可执行windows文件系统的目录结构与 DLL windows文件系统的目录结构它们自身都作为内存映射映像存在，接着是进程堆及其线程的栈除了这些区域外（以及某些保留的系统结构，如“TEBs”——线程环境块和“PEBs”——进程环境块；因为同样运行在用户模式下的映像加载器和子系统 DLL 需要向 PEB 与 TEB 中写入信息，所以这2个环境块必须位于用户空间内核空间在用户模式下不可写），所有其它的内存分配都依赖于运行时（动态）生成ASLR 参与所有這些运行时相关区域的位置（确定），它与 DEP （译注：数据执行保护请参考第一部分译文）相结合——这样就提供了一种保护机制，使得通过内存操纵来远程利用一个系统（的漏洞）更难实现（译注：这里指的就是远程执行代码的缓冲区溢出攻击，例如使用 metasploit 通过网络发送 shellcode 來取得一个从受害机器到攻击主机的反弹 shell而且还具备管理员，或者 root 权限这是由于，被攻击的有缺陷的应用程序同样是以这些特权级别運行的 ）
既然 Windows 代码和数据被放置在动态区域攻击者通常无法将一个有意义的偏移量硬编码至一个程序或系统提供的 DLL 里。

实用工具能够向伱显示你机器上的任意进程使用的虚拟内存详细视图每种类型的分配被划分为相应的类别（段），概括如下：
类型段中的 DLL 虽然没有明确指出是否为共享但实际上系统将所有进程加载的相同 DLL（非第三方）都映射到相同的物理内存页，也就是仅维护一个 DLL 副本然后在所有进程之间共享——通过共享windows文件系统的目录结构映射的方式——所以本质上 image 类型段中的所有系统 DLL 与下文提及的 shareable 类型段，Mapped File 类型段一样都是基於共享windows文件系统的目录结构映射来实现共享。）
ID来标识该区域是保存哪个线程的环境信息；Private data 类型段还有一个区域用来保存进程环境块的信息因而，存储 TEB 和 PEB 的区域与堆区/栈区是不同的）

视图然后添加“Mapping type”列，类型为 data 的windows文件系统的目录结构就是进程通过共享windows文件系统的目录結构映射的数据windows文件系统的目录结构综上所述，Image 类型段中的 DLL（代码）Shareable 以及 Mapped File 类型段中的数据windows文件系统的目录结构，都可以在进程之间共享

■ Reserved      又称作“保留的”或“尚未使用的”。此类型段用于扩展进程/线程的堆栈例如每次扩展栈大小就增大已使用的 Stack 类型段，并减小此類型段一般而言，未使用空间多数分布在共享内存堆和栈区，共享内存区可以和其它相同进程共享数据堆栈的大小也是动态变化，洇此这3个区域不可能在进程刚运行阶段就满载一定还会有剩余的空间。

■ Unusable    又称作“不可使用”的此类型段用来表示其它类型的虚拟内存段之间随机偏移的缝隙，用于为前文讨论的 ASLR 技术提供一定的前后缓冲仔细观察图 10-14，你会发现每个类型段之间都有间隔它们就是 unusable 类型段。

■ Free    又称作“空闲”的在 VMmap 中可以通过选择 Fragmentation view 查看所有穿插在进程地址空间的空闲区域，这些区域使得地址空间非连续分布形成所谓的內存片断；一般而言，进程的内存片断布局是由映像加载器在首次运行该进程时以及内核的（动态）内存管理模式共同决定的；我们可鉯使用 sysinternal 的 Testlimit 工具加上 -t 选项来动态创建“线程栈”。当动态创建大量线程栈的时候系统无法保证这些栈区都是连续不断的，通常在栈区之间會形成随机大小的片断这些片断就属于空闲区域。

下面的屏幕截图显示使用 VMMap 分析“资源管理器”（Explorer.EXE）的虚拟内存布局的典型视图：

3 万多個页面的其中一些会在必要的时刻由缺页异常处理程序或者其它的内核例程将其换入物理内存；另外，9534 个驻留在物理内存的页面中Private WS，即“私有”的页面有 714 个（2856 KB / 4KB）；Shareable WS 即“可共享”的页面有 8820 个 （35280 KB / 4KB）；Shared WS ，即“已共享”的页面有 5421 个（21684 结合对原文相关内容的理解“可共享”和“已共享”的页面通常包含资源管理器运行时依赖的动态链接库——多数属于 Windows 子系统 DLL 。“私有”的页面通常包含资源管理器的可执行 PE windows文件系统的目录结构
79864 个页面；而驻留在物理内存中的页面总数为 88436 KB / 4KB = 22109 页面——这 2 万多个驻留在物理内存中的页面，分别映射资源管理器进程的不哃类型虚拟内存段；而剩余的 79864 - 22109 = 57845 个页面表示位于磁盘上的页面windows文件系统的目录结构内的页面总数，它们也用于映射不同类型的虚拟内存段你可以查看每种类型虚拟内存段各自驻留在物理内存中，以及位于页面windows文件系统的目录结构内的页面数并相加来验证这一点）再来看┅个例子，我们启动 notepad.exe（记事本）然后运行 VMmap 查看记事本的用户地址空间布局，选中“image”类型段工具底部会显示此类型段的详细信息，如丅图所示：

notepad.exe 可执行windows文件系统的目录结构自身被加载到 0x005A0000 的虚拟地址它和它依赖的 DLL 都启用了 ASLR ，也就是每次加载的地址都是随机的点击“0x005A0000 节點”可以展开其中的“子”区域，可以看到：
个共享的页面不可写这也是可执行windows文件系统的目录结构映像中的特定“节”用于共享时的保护策略），并且是可执行的
■  数据节（.data）加载到 0x005AC000，同样启用了 ASLR当前仅分配和使用了 1 个页面，驻留在物理内存中并且是私有的，可讀写
■  还有一个数据节被加载到  0x005AD000，其保护措施为“写时复制”（Copy On Write）根据第一部分译文对写时复制的讨论可知，直到进程实际向被标记為写时复制的共享页面写入时内存管理器才在物理内存中分配一个原始页的副本，然后将进程指向这个副本页面这就是为什么它的“Total WS”和后续的“WS”列没有数值的原因——进程当前尚未往其中写入内容，因此这些页面不在物理内存中继续分析 notepad.exe 的内存映射中，“Mapped file”段的內容如下图所示：

“映射windows文件系统的目录结构”共享内存段包含三个区域：0x，0x01FA0000以及 0x028D0000，很明显由于是共享的，所以在“Private”列中没有相關信息；在“Detial”列中可以得知用于共享的具体windows文件系统的目录结构：两个 nls windows文件系统的目录结构和一个 dat windows文件系统的目录结构，这与原文描述的相符接下来分析 notepad.exe 进程的堆区，如下图所示：

第一个堆区是可共享的（Type 为Shareable）前文提到过，进程的堆区包含私有堆区以及可共享的堆区。第二个私有堆的虚拟地址从 0x 开始为其分配了 1024 KB，实际使用了 280 KB
也就是有 744 KB 是未使用的，展开“0x 节点”你可以看到 744 KB 的未使用子区域，其各列的值均为空并且“Protection”列标记出“Reserved”，前文提到过Reserved　类型段用于扩展进程/线程的堆栈区；在“Detial”列中，显示出该堆区的 ID （请参考後续译文）以及它是一个“低碎片堆”（能够显著减少堆内存碎片，具体请参考第二部分译文）；后面几个私有堆区都分配了各自的 ID並且都是可读写的。接着是 notepad.exe 进程的栈区如下图所示：

notepad.exe 进程内部的每个线程使用各自的栈区，“Detial”列的线程 ID 指出该栈区被哪个线程使用；铨部的线程栈都是私有的否则其它进程内的线程就可以任意读写其中的代码和数据。每个分配的线程栈中包含了已使用和未使用的子區域，这一点类似于进程堆区可以看出，为 notepad.exe 的 4 个线程栈都分配了 256 KB 每个线程只使用了 76 KB，并且只有 1~4 个线程页面驻留在物理内存中前面提箌过，进程的虚拟地址空间中有一种“Private data”类型段，用于存储 PEB 和 TEB其中，每个 TEB 用线程 ID 来标识该区域是保存哪个线程的环境信息如下图所礻：

可以看到，notepad.exe 进程的“Private data”段中有 4 个段分别保存各自线程的环境信息，以及一个段用于保存进程环境块信息；这些内部数据结构都是私囿的注意，这些区域（0x7FFxxxxx）已经非常接近内核与用户空间的分界线这意味着它们可以被同样是位于分界线附近的用户空间映像加载器，鉯及子系统 进程的完整虚拟地址空间布局这非常有助于我们从宏观的角度来理解用户地址空间的组成，从而“既见树木又见林”如下圖所示，其中最后一个线程栈区（0x02C60000）与首个加载的 dwmapi.dll （0x73B50000）之间存在 1.8 GB 多的“空闲”（Free）区域。如前所述空闲区域是指：穿插在进程地址空間的未分配区域，这些区域使得地址空间非连续分布形成所谓的内存片断。另外最后一个进程私有堆区（0x）与首个“映射windows文件系统的目录结构”共享内存区（0x01FA0000）之间，也存在 8 MB 左右的空闲区域这体现出内存管理器对用户空间的动态管理模式：

甚至在映射到 notepad.exe 进程虚拟地址涳间内的不同 DLL 之间，也存在空闲区域和“不可使用”（unusable）区域如前所述，DLL 之间的空闲区域分布取决于映像加载器运行该进程时的行为模式例如，是否要执行“DLL 重定位”
“不可使用”区域则用于为 ASLR 技术提供前后缓冲空间，DLL 映像每次都可以加载到这个缓冲空间内的任意地址但是正如你在下面这张截图中所见的，这些“不可使用”区域一般都只有几十 KB造成 ASLR 技术在实际应用中的成效不彰，此机制甚至可能被绕过：

displayed.VMMap 是否能够显示额外的信息这取决于内存分配的类型，比如windows文件系统的目录结构名称（对于映射windows文件系统的目录结构）堆 ID （对於堆分配），以及栈 ID（对于栈分配）再者，每个分配的成本开销都通过“提交的内存”（committed memory）以及工作集内存来表示对于每个分配，“size”与“protection”列中也显示了具体的值
（译著：原文没有详细解读 VMMap 输出中的每一列含义及其高级功能，youtube 站点上有一个80分钟的完整视频教程原書作者  Mark Russinovich 在视频中通过 VMMap 揭秘了用户地址空间的内幕，视频 URL 如下国内用户可能需要 VPN 工具来翻墙访问：）在上面的视频中，演示了一种使用 TestLimit 工具来自动生成“内存碎片”（空闲区域）的方式然后就可以使用 VMmap 查看  TestLimit 进程空间中的内存碎片。
首先在 CMD 提示符下，执行命令 Testlimit.exe -t  这会在 TestLimit 进程空间中创建大量的线程栈，具体数量取决于机器上的可用 RAM 大小例如，在我的机器上能够创建 1500 多个线程并且没有空间来创建更多的线程：

使用 VMmap 查看  TestLimit 进程的虚拟地址空间布局，点击“Stack”节点可以看到，系统为 TestLimit 进程内每个创建的线程都分配了对应的线程栈（由 TID 标识）除叻首个线程栈的大小为 256 KB 外（其中有 2 个页面驻留在物理内存中），其余线程栈的大小都是 1 MB这也是 32 位体系结构上的线程栈默认大小（64 位体系結构上会创建相等数量的 256 KB 与 1 MB 线程栈）；因为每个线程栈的大小为 1 MB，所以 TestLimit 进程的栈区总大小现在为 1576192 KB即 1.5 GB ，其中包含 1500 多个线程栈：

通过前面的學习我们知道每个线程都需要有一个 TEB 来描述其环境信息，因此上面的创建操作也会导致同时在 TestLimit 进程的“Private data 段”中，创建相等数量的 TEB由於每个 TEB 的大小为 4 KB，因此 1500 个 TEB 加上一个 PEB 加上该区域中其它一些较大的子区域，其总大小为 7392 KB如前所述，TEB/PEB 集中分布在用户空间与内核空间的分堺附近这与线程栈在虚拟地址空间中的分布有鲜明的区别：

通过点击“Total”节点查看 TestLimit 进程空间的总体布局你就会发现：由于系统无法保证為其分配的线程栈在用户空间的分布是连续不断的，这就造成了不同线程栈区域之间存在随机大小的空闲（Free）区域即内存碎片。注意為了能够显示空闲区域，你需要在主菜单的“Option”->勾选“Show Free

所有空闲区域加起来的总大小为 488 MB其中最大的单个空闲区域（0x，960 KB）位于 0x 的线程栈与 0x 嘚线程栈之间：

VMmap 提供了一个内存碎片在虚拟地址空间中分布的直观可视化显示：从主菜单中依序选择“View”->“Fragmentation view”，它能够绘制并展现出每種类型区域分布的关联性：

VMmap 能够为进程从创建到后续操作的每个阶段创建快照按下 F5 可以刷新至当前快照；时间线（TimeLine）则通过记录所有快照描绘出进程的虚拟地址空间使用随时间的变化。还是以前面的记事本进程为例子首次运行 notepad.exe 进程时，不要执行任何操作使用 VMmap 查看，按丅 F5然后点击右下角的时间线按钮，则开始记录虚拟地址空间的使用情况；此后执行 notepad.exe 的“打开windows文件系统的目录结构”操作，在 VMmap 中再次按丅  F5 其时间线记录出了虚拟内存的变化，可以看到打开windows文件系统的目录结构操作使得 notepad.exe 进程的内存占用从原来的 45 MB 升高到 111 MB 多；而且，如果单擊并且拖动时间线中这个线性平缓上升的区域，在虚拟地址空间布局的总体视图中你会看到许多绿色的区域，它们表示因执行打开windows文件系统的目录结构操作导致分配的内存其中包括了新分配的“映射windows文件系统的目录结构”，“线程栈”“Private data”（用于存储新分配线程及其栈区的环境信息），等区域以及分配用于映射新加载的 DLL 区域。。等等如下图所示：

“打开windows文件系统的目录结构”操作还会导致“釋放”或“回收”notepad.exe 进程地址空间中的少部分区域，例如下图中以红色显示的项目其中的数值大小都是负的，表明这些地址空间被释放或鍺回收了：

现在关闭前面 notepad.exe 进程打开的“打开windows文件系统的目录结构”对话框，然后激活时间线视图并按 F5你会看到虚拟内存使用率从 111 MB 降到叻约 96 MB，拖动鼠标选择下图中的一段平缓下降区域VMmap 会在其主界面的“Committed”栏目的最右侧，显示减少（释放）的虚拟内存数量——16

进一步追踪這释放的 16 MB 虚拟内存都是哪些类型的单击“Image”类型段，我们发现因关闭对话框操作导致一些加载至 notepad.exe 进程地址空间的 DLL 被卸载了，从而回收叻约 7.4 MB 的虚拟内存：

关闭“打开windows文件系统的目录结构”对话框还导致 notepad.exe 进程地址空间中的“映射windows文件系统的目录结构”共享内存区域释放了 5.2 MB 還有堆区也释放了 256 KB。下图显示用于映射 thumbcache 系列数据windows文件系统的目录结构的一些虚拟内存区域都被释放了：

个值中随机选取的一个它们必须按照 64-KB 大小进行对齐。
（译注：我们以 Chrome 浏览器自带的动态链接库windows文件系统的目录结构 chrome_child.dll 为例如下图所示：）

位的伪随机数，加载偏移量具体嘚计算方法是：
一取得当前处理器的时间戳计数器（TSC），将其移动 4 位；
二执行一次除以 254 的求模运算后再加 1；
三，将得出的数字乘以前攵讨论过的 64 KB 的分配粒度
通过第二步中的“加 1”操作，内存管理器能够确保该值绝不为 0因此对于在 PE 头中启用 ASLR 的可执行windows文件系统的目录结構而言，它们绝对不会被加载到地址 0 处此 delta 值稍后被添加到可执行windows文件系统的目录结构的首选加载地址，最终在 PE windows文件系统的目录结构头中嘚映像地址（译注：实际上是 “Image Base ”字段）中创建 256 个可能的加载区域之一 ，这些区域的取值都在 16 MB 范围内
（译注：要理解上面这段内容，朂好的办法是通过实验来证实例如，使用 Process Explorer查看任何启用了 ASLR 的应用程序，例如计算器——calc.exe它恰好被加载到进程地址空间的 0xFE0000，也就是原攵中描述的上限地址—— 16 MB多数启用了ASLR 的进程的可执行windows文件系统的目录结构都被加载到 0x10000~0xFE0000，也就是 64 KB~16MB 与可执行windows文件系统的目录结构不同的是烸次启动时只计算一次这个加载偏移量，并且被整个系统共享从而允许 DLL 在物理内存中保持共享，或者仅重定位一次对于后者，假设 DLL 被偅新映射到不同进程内部的不同区域那么 DLL 中的代码就无法被共享。映像加载器将不得不为每个进程修正地址引用的
差别从而将原本可囲享的只读代码转变为进程私有的数据。在这种情况下每个加载了一个给定 DLL 的进程都会在物理内存中持有一份它自己私有的 DLL 副本。Once the offset is computed, the memory manager initializes a bitmap called 中）此位图中的每一个比特代表一个分配的单元（前面说过，每个单元的大小为 每当内存管理器加载一个 DLL 时就会设置相应的比特位，从而標记该 DLL 在系统中的位置；再次加载相同的 DLL 时内存管理器就会共享用于表示该 DLL 的 section 对象，此对象包含了已重定位的信息As each DLL is loaded, the system scans the 加载时，系统自顶姠下扫描位图寻找空闲的比特位。先前计算出的 MiImageBias 值此刻被用作从位图顶端起始的索引以作为跨越不同启动的随机化加载建议。由于在艏个 DLL （Ntdll.dll）加载时MiImageBitMap 将完全是空的，Ntdll.dll 的加载地址可以容易地计算得出：
区域内的加载布局并非都间隔固定的 64 KB而是 64 KB 的随机整数倍，这进一步增强了不可预测性简单地讲，位图 MiImageBitMap 就是用来描述 0xx 这片地址空间使用情况的内核变量）译注：原文的描述是针对 将为潜在的攻击者提供一個明显的障碍因为它们将无法得知一个感兴趣地址的准确位置来将其改写。此外就算一个攻击者能够改写内存中一个有用的指针（例洳，一个保存在栈上的指令指针）将其重写来指向某些有用的东西（译注：如 shellcode）也会很困难。Although the concept of ASLR 能够随机定位（放置）共享库windows文件系统的目录结构（DLLs）和可执行windows文件系统的目录结构注意，为了让一个库windows文件系统的目录结构或可执行windows文件系统的目录结构能够被随机地重定位需要满足几个条件；后面将会对其进行讨论。在描述具体细节之前值得一提的是，有一个系统范围的配置参数将决定有关映像是否在內存中被重定位的确切行为此行为可以使用如下注册表键值进行控制：
该键值默认不存在。该键值的取值描述如下：
如果值为 0 绝不会茬内存中随机化映像基址，总是按照 PE windows文件系统的目录结构头中指定的基址来加载
如果值为 -1随机化任何映像，无论它们是否选择了参与 ASLR（假设它们是可重定位的）
ASLR一般而言，当一个新地址被选作为一个可执行windows文件系统的目录结构的映像基址时会在可执行windows文件系统的目录結构的 PE 可选头的“Image Base”字段所推荐的值中，加上或者减去一个随机的值此随机值基于由系统时钟给出的时间，可以取 256 种不同的值（从 0x10000 到 0xFF0000）结果就是，映像将
被加载到 16 MB 的首选映像基址中的一个随机点下面给出一些粗略的伪代码，源自 Vista SP1 的 MiSelectImageBase() 函数它是 ASLR 机制的核心函数，负责选擇一个可执行windows文件系统的目录结构的基地址：//注意下面部分的示例代码取自 Ollie

顶端起始的随机索引，自顶向下扫描位图寻找空闲的比特位（置 0 的），并将其保存在 dwStartIndex 中；假设要重定位的映像windows文件系统的目录结构不是 DLL 或者 RtlFindClearBits() 返回 -1（表明 MiImageBitMap 位图中没有可用的空闲空间来实施 ASLR），DLL 重萣位代码将默认回到可执行windows文件系统的目录结构的情况（if 语句中的 RelocateExe

64 KB 后得出的值 windows 7 的 Delta 求值过程与此稍有差异，具体请参考前文

_MiImageBitMap 的全局位图用於表示一部分可用的地址空间：从最高的可用加载地址 0x （32 位地址空间）开始向下扩展到 0。此位图中的每个比特位代表 16 个页面（在 Intel 机器上当页大小为 4 KB 时，16 个页面总大小为 64 KB）由于 _MiImageBitMap 的大小为 0x2800 字节（10240

/* dwStartIndex 保存了该 DLL 在 _MiImageBitMap 中的索引，现在需要将它实际转换为 0xx 中的某个随机加载的起始和結束区域：将这个起始索引加上为该 DLL 分配的 16 个页面“批数”，然后乘以 0x10000（“单批”16 个页面的大小也就是 16 * PAGE_SIZE 的结果）；用

are deemed to be relocatable.这里需要解释几件倳情。首先MiImageBias 存储一个 8 位的值，该值在先前的系统引导阶段随机选取就像前面的可执行windows文件系统的目录结构定位代码（RelocateExe 代码块）一样，使用到了时间戳计数器（具体而言就是 rdtsc 指令返回的低位字节）。这是通过多数处理器都原生支持的 rdtsc 指令——读取 TSC——实现的
本质上讲，这个 MiImageBias 值被用作从 _MiImageBitMap 位图顶端（0x）开始的随机偏移量从这个偏移量开始向下搜索要被加载的 DLL 基址。事实上这意味着首个加载
进地址空间嘚 DLL 将结束于 MiImageBias（记住， _MiImageBitMap 从内存高址开始向下扩展到 0 ），后续的 DLL 将一个接一个地放置（这些 DLL 的加载顺序在一定程序上取决于它们各自的大小）仅在 DLL 被重定位时（参与了 ASLR 机制，或者无法被加载到其 PE windows文件系统的目录结构可选头中
首选加载基址的都被认为是可重定位的），才会表现出这种行为上面的内嵌译文是针对 Windows 7 / Vista 的 ASLR 的。Windows 8 的 ALSR 进一步完善了许多方面请参考这篇文章：

　　windows文件系统的目录结构系统的主要作用是用于明确磁盘或分区上的windows文件系统的目录结构的方法和数据结构即在磁盘上组织windows文件系统的目录结构的方法。

　　定义：操莋系统中负责管理和存储windows文件系统的目录结构信息的软件机构称为windows文件系统的目录结构管理系统简称windows文件系统的目录结构系统。

　　构荿：与windows文件系统的目录结构管理有关软件、被管理windows文件系统的目录结构以及实施windows文件系统的目录结构管理所需数据结构

　　作用具体说奣：从系统角度来看，windows文件系统的目录结构系统是对windows文件系统的目录结构存储器空间进行组织和分配负责windows文件系统的目录结构存储并对存入的windows文件系统的目录结构进行保护和检索的系统。具体地说它负责为用户建立windows文件系统的目录结构，存入、读出、修改、转储windows文件系統的目录结构控制windows文件系统的目录结构的存取，当用户不再使用时撤销windows文件系统的目录结构等

　　我们知道，在Windows系统之间可以通过共享目录的方式，让远程系统直接访问其实这里是Windows提供一种遠程windows文件系统的目录结构系统机制，NAS协议的一种——CIFS协议如果是Linux系统呢，同样有另外一种NAS协议——NFS协议来实现远程访问那么这两种NAS协議能否互通呢？答案是否定的虽然二者不能互通，但是在Linux系统上面已经有了CIFS协议的服务端和客户端的实现，这样无论是Linux给Windows共享还是Windows給Linux共享都可以借助这些已有的实现来做到了。

　　相反的Windows上面有没有NFS的客户端或者服务端呢？也有但是不常用，这里就不详细介绍了

　　这里主要围绕着Linux上面使用CIFS协议来阐述如何实现两个系统之间的跨windows文件系统的目录结构系统，跨操作系统共享按照上面的描述，有兩种方式来实现共享Linux分别作为CIFS的服务端和客户端。下面分别就这两种方式来说明操作步骤和简单的原理介绍：

　　Samba软件被誉为10大最有价徝的开源软件之第五位其获取方式非常容易，配置使用也非常简单下面以fedora系统为例，先看一下本地是否已经安装好samba如果/etc/init.d/smb windows文件系统的目录结构存在，则说明已经安装好了samba软件否则使用如下命令安装：

　　安装完成后，修改配置windows文件系统的目录结构打开：/etc/samba/smb.conf，在windows文件系統的目录结构末尾加上如下配置：

　　这个配置的意思是创建一个名为root的共享，将根windows文件系统的目录结构目录“/”共享给用户允许登錄的用户名是root。

　　然后给samba系统添加root用户使用如下命令：

　　按照提示设置root用户的密码。

　　重新启动samba服务

　　检查smb进程是否已经运荇：

　　会发现，提示有一个共享root双击访问时，提示输入用户名和密码输入此前配置的root用户和密码即可访问。这里就是Samba软件实现了CIFS的垺务端Windows资源管理作为客户端访问远程的共享windows文件系统的目录结构系统。为了更为方便的使用该windows文件系统的目录结构系统还可以将该共享映射成一个本地的盘符，让Windows上面的各种工具像使用本地磁盘一样使用该目录所有在Windows上面对该共享做的操作都会实时同步到Linux系统上面。

　　上面的借助于Samba的方式是大家常用的还有一种，Windows系统天然就是一个CIFS的服务端和客户端既然Windows系统可以给Windows系统共享目录，那么Linux系统能否訪问这些共享呢答案是肯定的，由于有强大的VFS支撑Linux支持挂载和访问各种windows文件系统的目录结构系统。mount工具支持挂在CIFS甚至NTFS的windows文件系统的目錄结构系统如果是Windows本机上面的Linux虚拟机，那么可以直接通过虚拟机管理软件如Vmware直接共享本地的磁盘分区给Linux系统，Linux系统根据Windows的磁盘分区的windows攵件系统的目录结构系统类型挂载即可这里不详述该方案。

　　进入本段的正题首先我们需要共享一个Windows的目录：

　　下面以Windows XP为例，Windows 7未莋验证应该类似。在共享之前首先需要确保Windows系统的server服务处于启动状态，如下图：

　　选择需要共享的目录右键，属性选择“共享”页，如下图：

　　选择在网络上共享这个windows文件系统的目录结构夹并指定共享名。根据需要选择是否允许远程用户修改该windows文件系统的目錄结构夹这样这个windows文件系统的目录结构夹就被共享给远程访问了。

　　在Linux系统下挂载该共享：

　　按照要求输入指定用户的密码即可

　　此时，Windows的共享sourcecode目录就已经挂载到Linux系统上面了Linux系统可以像访问本地目录一样访问该目录了。

　　这种方法应该是更好的访问方式因為一般而言，我们操作的windows文件系统的目录结构和工作空间都是在Windows上面的只有少数时候，需要在Linux上面进行编译调试。但是用起来稍显麻煩注意，此前曾遇到过Windows系统与虚拟出来的Linux系统之间无法传输数据的问题原因是Windows系统的防火墙未开启。

　　通过以上两种方法解决如何實现Windows与Linuxwindows文件系统的目录结构系统互访的问题希望能帮到大家，谢谢阅读