《虚拟机隔离运行模型.docx》由会员分享，可在线阅读，更多相关《虚拟机隔离运行模型.docx（69页珍藏版）》请在三一办公上搜索。
1、第三章 隔离运行模型本章提出了一种新的基于虚拟机技术的隔离运行模型SVEE，该模型满足满足操作系统隔离、应用透明、计算环境重现、隔离程序执行效果跟踪与操作系统信息重构等五个应用约束，平衡了安全隔离性、功能完整性、性能适应性和行为可监控性。同时，本章给出了该模型的形式化安全性分析和度量，通过理论分析阐明了 SVEE 能够满足 Bell-LaPadula 机密性模型和 Biba 完整性模型。并进一步论证了在此模型下，被保护的宿主环境的容侵能力也将得到有效提升。基于此模型，本章构造出以本地虚拟化技术为核心的满足 SVEE 隔离运行模型的体系结构，该体系结构独立于操作系统实现，具有很好的可移植性。通过
2、对现有虚拟机模型的详细分析，指出 Type II 虚拟机模型能够最有效地在个人计算平台下支持这五个约束条件。本章工作是后继章节所做工作的理论基础。3.1 隔离运行模型对于隔离运行非可信软件的运行环境而言，为了实现操作系统与应用程序透明的目标，同时能够重现已有的软件运行环境并支持操作系统语义信息的重构，即在保证安全隔离性的前提下提升隔离运行环境的功能完整性、性能适应性与行为可监控性，该环境必须满足以下约束条件。l 约束 1：操作系统隔离：非可信软件必须运行在一个与宿主操作系统隔离的虚拟计算机系统中，这是抵御特权恶意代码攻击、确保安全隔离性的必要条件。l 约束 2：应用程序与操作系统透明：现有操作
3、系统、应用程序和将被隔离的非可信软件均不需作任何修改即可直接布署该隔离机制，这一点在个人计算平台下尤其重要。此约束包含四个子约束： 约束 2A：无需修改现有操作系统与应用程序及其将被隔离的非可信软件的源代码，因为通常个人计算平台上流行的应用程序与操作系统（如 Windows）都未开放源代码。 约束 2B：不能限制非可信软件在隔离运行环境内访问的资源与执行的特权操作，这是保证隔离运行环境的功能完整性的必要条件。 约束 2C：尽可能地将隔离机制对可信代码运行环境造成的性能影响最小化，即在确保安全隔离性的同时兼顾系统的可用性。 约束 2D：无需重新安装现有操作系统。个人用户中绝大部分不是计算机专业技
4、术人员，所以个人计算平台上往往都预装有操作系统，所以在布署隔离运行技术时必须保证能够继续使用原有操作系统。l 约束 3：可配置的计算环境重现：由于非可信软件的正常执行与执行效果通常依赖于计算环境，尤其是文件系统内容与操作系统配置等，所以在隔离运行环境内重现宿主操作系统的计算环境既是保证隔离运行环境的功能完整性的要求，也是减少布署开销的必要条件。本约束可细化为： 约束 3A：计算环境的重现不应通过复制整个计算机的软硬件系统的来实现，这样的布署开销通常不能被个人用户接受。 约束 3B：为了提高系统机密性，被导出到隔离运行环境中的宿主计算环境资源应该是可配置的，被隔离软件只能访问这些资源，涉及敏感信
5、息的数据不应在隔离运行环境中重现。这是确保安全隔离性的必要条件。 约束 3C：尽可能地使隔离运行环境的性能接近宿主环境，这是提升性能适应性的要求。l 约束 4：隔离程序执行效果的跟踪：隔离运行环境必须能够跟踪和记录被隔离软件对数据的修改操作，从而为分析程序行为与提交相应程序的执行效果到宿主环境提供依据，这也是提高系统可用性与隔离运行环境的行为可监控性的关键。l 约束 5：支持操作系统语义信息重构：这里的语义信息是指操作系统抽象层的资源的信息，如进程、线程、文件、用户等。用户或相关工具程序只有借助隔离运行环境的这些信息才能精确分析隔离运行环境内应用程序和操作系统的行为，进而提升隔离运行环境的行为
6、可监控性。(a) 基于 Type I VMM 的 Native 隔离运行模型 (b)基于 Type II VMM 的 Hosted 隔离运行模型图 3.1 SVEE 的基于不同 VMM 的两种可选隔离运行模型为了满足约束 1，SVEE 必须利用虚拟机监视器（Virtual Machine Monitor，VMM）来创建非可信软件的运行容器虚拟机。只有这种基于硬件抽象层的虚拟机技术才能实现操作系统的隔离。按照 Goldberg 的定义，VMM 是能够为计算机系统创建高效、隔离的副本的软件。这些副本即为虚拟机（Virtual Machine，VM），在虚拟机内处理器指令集的一个子集能够直接在物理处
7、理器上执行。Goldberg 定义了两种 VMM：Type I VMM 和Type II VMM。Type I VMM 直接运行在计算机硬件系统上，负责调度和分配系统硬件资源，可以将其理解为一个实现了虚拟化机制的操作系统。而 Type II VMM则以一个应用程序的形式运行在已有的传统操作系统之上，而这个实际控制系统资源的操作系统被称为宿主操作系统（Host OS），运行在 Type II 虚拟机中的操作系统则被称为客户操作系统（Guest OS）。基于这两种不同的虚拟机监视器，SVEE就有了相应的两种隔离运行模型（如图 3.1 所示）：基于 Type I VMM 的 Native隔离运行模型
8、和基于 Type II VMM 的 Hosted 隔离运行模型。对于约束 2A，作为硬件抽象层的虚拟机，Native 隔离运行模型中的 Type IVMM 与 Hosted 隔离运行模型中的 Type II VMM 均无需修改已有应用程序和将被隔离的非可信软件的源代码。Type II VMM 的实现不需要修改宿主操作系统，而 Type I VMM 是否需要修改操作系统则依赖于其实现技术，如基于动态指令转换技术则无需修改（如 VMware ESX Server），基于半虚拟化技术（Para-Virtualization）且没有硬件虚拟化技术的支持则需要修改运行在 VMM 之上的操作系统源代码（如
9、 Xen）。由于 Type I VMM 与 Type II VMM 这两种虚拟机技术均对上层应用提供了完整的虚拟化计算机硬件平台，VMM 之上运行的软件（操作系统）就像在真实的物理计算机系统上运行一样，无需限制代码访问的资源与执行的特权操作，因此这两种隔离运行模型均能满足约束 2B。约束 2C 强调的是保证可信代码运行环境的性能。如图 3.1 (a)所示，在 Native隔离运行模型中，所有操作系统都运行于虚拟机之上，所以不可避免地导致可信代码运行环境性能的下降。而基于 Type II VMM 的 Hosted 隔离运行模型的可信代码运行环境即为传统的操作系统，高效地直接运行于硬件系统之上。因
10、此，在尽可能减少影响可信代码运行性能这一点上，基于 Type II VMM 的 Hosted 隔离运行模型优于 Native 隔离运行模型。而对于约束 2D，在 Native 隔离运行模型中，需要用 VMM 替换原有的操作系统，这往往对于个人用户来说是无法接受的，而即使用户接受，要替换现在所有的个人计算平台上的操作系统也是一个非常漫长的过程。与此相反，Hosted 隔离运行模型则可以与已有操作系统共存。约束 3C 关注的是隔离运行环境的性能可适应性。与 Type I VMM 相比，Type II 虚拟机中的虚拟 I/O 设备性能不及 Type I 虚拟机。但是随着硬件虚拟化技术的普及、应用与提
11、高，以及各种虚拟 I/O 设备优化技术研究的不断发展，这种性能差距将逐渐缩小。约束 3（3A 和 3B）、约束 4 和约束 5 均与具体的虚拟机监视器模型无关，而对于这三个约束，Native 隔离运行模型和 Hosted 隔离运行模型均需要添加额外的机制才能支持，这也是 3.2 节（SVEE 体系结构）需要解决的问题。此外，从软件开发的角度来看，Native 隔离运行模型中的 Type I VMM 实际上是将传统操作系统的硬件资源管理功能下移到 VMM 中。但在个人计算平台下这种机制有一个明显的不足：个人计算平台上硬件设备的多样化将会极大地增加Type I VMM 开发的复杂性。个人计算平台开
12、放的体系结构导致计算机系统有类型繁多的硬件设备，而直接运行在硬件系统之上 Type I VMM 则需要管理这些设备，因此为它们编写相应的驱动程序将是工程浩大的工作。与此不同，Type II VMM 可以直接利用操作系统提供的设备抽象接口，极大简化 VMM 的开发，从而可以有效提高 VMM 的稳定性。综上所述，除了约束 2C 和约束 2D，这两种隔离运行模型均能够满足其他约束。但是，由于 SVEE 主要针对的是个人计算平台，而 Hosted 隔离运行模型在个人计算平台下具有显著优势，因此 SVEE 采用了基于 Type II VMM 的 Hosted 隔离运行模型。在这种模型下，SVEE VMM
13、 以 Type II VMM 的形式运行在宿主操作系统之上，并负责创建本地化启动的 SVEE 虚拟机作为执行非可信软件的运行环境。运行在本地化启动的 SVEE 虚拟机之上的客户操作系统是宿主操作系统的一个副本，因此非可信软件在宿主操作系统上的行为得以精确重现，同时将其执行效果同宿主运行环境彻底隔离。3.2 系统体系结构为了满足前文中描述的五个约束，SVEE 引入了本地虚拟化技术（Local Virtualization Technology）以实现可配置的计算环境重现。SVEE 基于 Type II VMM 的 Hosted 体系结构如图 3.2 所示，SVEE 由五个核心组件构成：SVEE
14、虚拟机监视器（SVEE VMM）、基于卷快照（Volume Snapshot）的虚拟机简单磁盘（Virtual Simple Disk）、操作系统动态迁移管理器（OS Dynamic Migration Manager）、修改跟踪管理器（Change Tracking Manager）和隐式操作系统信息重构组件（Implicit OS Information Reconstructor）。如 SVEE 隔离运行模型所述，SVEE VMM 需要以 Type II VMM 的形式实现，即在宿主操作系统之上运行。SVEE VMM 负责创建非可信软件的隔离运行环境SVEE 虚拟机（SVEE VM）。借
15、助基于卷快照的虚拟机简单磁盘和操作系统动态迁移管理器，SVEE 实现了本地虚拟化技术，即 SVEE 虚拟机中无需重新安装操作系统（这是现有虚拟机软件的运行模式），而是直接从宿主操作系统启动，启动后的操作系统即为“本地启动操作系统”（Local-Booted OS）。图 3.2 SVEE 体系结构修改跟踪管理器则记录 Local-Booted OS 和宿主操作系统（Host OS）内的资源（如文件、注册表等）变化信息，为进一步分析被隔离软件的行为或之后将Local-Booted OS 的数据变化合并到宿主操作系统提供支持。隐式操作系统信息重构组件不依赖于操作系统提供的接口，能够利用硬件层的数据（
16、如处理器寄存器信息、MMU、磁盘信息等）重构出具有应用层语义的客户操作系统信息。3.2.1 虚拟机监视器如前所述，SVEE 虚拟机即为采用本地虚拟化技术启动的硬件抽象层虚拟机，被隔离的非可信软件就在由 SVEE 虚拟机启动的 Local-Booted OS 中运行，而可信程序则直接在宿主操作系统上运行。为了满足不能修改操作系统源代码的约束（约束 2A），SVEE VMM 不能采用半虚拟机技术，而只能采用与 VMware 虚拟机（包括 VMware Workstation 和VMware ESX Server）类似的动态指令转换技术。由于 Intel Pentium 处理器（x86 体系结构）在
17、目前的个人计算平台上最为流行，因此SVEE VMM需要重点解决的就是如何在Intel Pentium处理器上实现基于动态指令转换技术的 Type II VMM。Goldberg分析并提出了适合虚拟化的第三代硬件体系结构应该满足的四点约束：1. 具有两个以上的处理器操作模式。2. 非特权的程序能够通过一种方法来调用特权级的系统例程。3. 具有内存重定位或保护机制，如分段机制或分页机制。4. 具有异步的中断机制。John Scott Robin 等人则提出了关于处理器支持 Type I VMM 和 Type II VMM需满足的约束。由于 SVEE VMM 是以 Type II VMM 的形式实现
18、的，因此本文只讨论处理器支持 Type II VMM 需满足的约束条件。约束 1（R1） 无论在特权模式还是非特权模式下，非特权指令的执行语义都必须相同。例如，处理器不能通过在指令代码内添加特殊的比特位来标识处理器当前的特权级（Current Privilege Level，CPL）。这个约束实际上是对 Goldberg 提出的约束 1 的一个扩展。约束 2（R2）处理器必须提供一种保护机制或地址转换机制，能够对物理计算机系统和虚拟机之间进行隔离和保护。这一约束与 Goldberg 提出的约束 3 一致。约束 3（R3）当虚拟机试图执行敏感指令（Sensitive Instruction）时，
19、处理器必须提供一种机制使得虚拟机监视器能够自动得到通知，以便于其模拟出该指令的执行语义。按照 John Scott Robin 等的定义，敏感指令就是指所有需要操作虚拟机监视器或宿主操作系统状态的指令，主要包括如下四类指令：1. 读写当前虚拟机和物理计算机系统状态的指令；2. 读写敏感寄存器和内存的指令，例如读写时钟寄存器或中断寄存器的指令；3. 操作处理器提供的保护机制或是地址转换机制的状态的指令；4. 所有 I/O 指令。x86 处理器满足 Goldberg 提出的四个约束：具有从 0-3 四种特权级（Privilege Level），操作系统内核运行在 Ring 0 级，而应用程序则运行
20、在最低特权级上Ring 3 级；提供了调用门（Call Gate）机制，用以支持低特权级的程序调用高特权级的代码；提供了段/页式内存管理机制，以支持内存重定位和保护；提供了中断（Interrupt）和异常（Exception）两种机制使得 I/O 设备可以与处理器异步通信。图 3.3 处理器指令分类同理，Intel x86 处理器也满足 John Scott Robin 约束 R1 和 R2，但是它依然不支持虚拟化，这是因为它不能满足约束 R3。如图 3.3 所示，从处理器虚拟化和处理器特权级两个角度审视指令集，可将其分为四类：特权非敏感指令、非特权非敏感指令、特权敏感指令和非特权敏感指令。由
21、于前两种均为非敏感指令，所以可以在物理处理器上直接执行，无需虚拟机监视器做特殊处理。但是，正如处理器约束所规定的，虚拟机监视器必须解释执行所有敏感指令的语义而不能在物理处理器上直接执行。对于 x86 处理器而言，所有特权敏感指令的执行均会产生中断或自陷（Trap），因此虚拟机监视器可以通过设置相应的中断/自陷响应函数获得通知进而进行指令模拟。而使得 x86 处理器不支持虚拟化的就是第四类指令非特权敏感指令，与其它支持虚拟化的处理器不同，x86 处理器的指令集中存在非特权敏感指令，而这类执行的执行并不产生任何中断或自陷，从而虚拟机监视器无法获取相应的通知信息。John Scott Robin 等
22、已经分析了 x86 处理器的所有指令，指出其中包含了 17条非特权敏感指令，即 SGDT、SIDT、SLDT、SMSW、PUSHF（PUSHFD）、POPF（POPFD）、LAR、LSL、VERR、VERW、POP、PUSH、CALL, JMP、INT n、RET 和 STR。综上所述，在 x86 处理器上实现 SVEE VMM（Type II VMM）的关键就是如何模拟执行敏感指令，并且感知非特权敏感指令的执行。目前有三种方法可以处理非特权敏感指令：第一种技术是Denali 和 Xen 的半虚拟化技术，但是这种技术需要修改操作系统源代码，不能满足 SVEE 隔离运行模型的约束 2A；第二种技
23、术是 Intel 和 AMD 提出的硬件虚拟化技术，该技术通过修改处理器的实现使得处理器在虚拟化状态下执行非特权敏感指令时能够产生事件通知虚拟机监视器；但是考虑支持硬件虚拟化技术的处理器尚未普及，因此 SVEE VMM 采取了第三种技术，即“动态指令转换技术”，使得SVEE VMM 通过运行时指令转换将原本不产生自陷的非特权敏感指令替换为具有通知 VMM 功能的指令。3.2.2 基于卷快照的虚拟简单磁盘对于本地虚拟化技术而言，关键问题是如何与宿主操作系统共享已安装在系统卷上的操作系统映像。因为 SVEE 虚拟机需要访问系统卷以启动 Local-Booted OS，而此时宿主操作系统也在修改系统
24、卷，前者对数据的修改并没有使用宿主操作系统提供的访问接口，后者的修改信息也无法及时被 SVEE 虚拟机内的文件系统感知，这就造成了文件系统数据与磁盘数据的冲突，操作系统关键文件的不一致将会导致系统的崩溃。为了解决这个问题，本文提出了基于卷快照的虚拟简单磁盘（Virtual Simple Disk）技术。卷快照是在其创建时刻它所对应的原始卷的一致性副本，它提供了与文件系统标准卷相同的访问接口。而虚拟简单磁盘则是卷快照（必须包括系统卷的快照）与虚拟分区表的集合，它是将卷快照以存储设备的形式导出到 SVEE 虚拟机的实现方式。此外，在将卷快照导出到 SVEE 虚拟机前，用户可以安全删除不允许在 Lo
25、cal-Booted OS 中访问的目录、文件等敏感数据。从实现的角度，创建整个磁盘的快照比导出卷快照的方式更加直观。但是对于 SVEE 来说，组合卷快照的虚拟简单磁盘主要有如下三个优势：l 便于配置导出的卷：如直接使用磁盘快照，则该磁盘内所有的卷均会被导出到SVEE 虚拟机中，这往往违背了用户的安全性和可配置性的需求。而通过配置虚拟简单磁盘，只有用户明确需要导出的卷才能在 SVEE 虚拟机中访问；l 卷格式透明：目前广泛应用的操作系统均支持多种卷格式，如单分区卷与多分区卷等，多分区卷包括镜像卷（Mirror Volume）、RAID-0 卷和 RAID-5 卷等。所以如果直接导出磁盘快照，那
26、么如该磁盘内含有多分区卷，则也必须导出该卷依赖的所有磁盘。但是以卷快照为导出的基本单位则避免了这个问题。l 便于操作快照数据：卷是文件系统加载的基本单位。通过加载卷快照，用户可以方便直观地访问快照数据。3.2.3 操作系统动态迁移管理器基于卷快照的虚拟简单磁盘解决了文件系统的冲突问题，但本地虚拟化技术的实现还需要解决软件服务的不兼容问题。由于 SVEE 虚拟机是直接从宿主操作系统启动，因此所有启用的系统服务和开机自动运行的软件都将在 SVEE 虚拟机启动时运行。由于 SVEE 虚拟机与宿主硬件环境的差异，依赖于硬件系统的系统服务可能会导致 SVEE 虚拟机启动时挂起甚至崩溃。为了解决这个问题，
27、本文引入了隐式进程标识技术（将在第六章介绍），该技术能够在虚拟层标识客户操作系统中的进程（包括当前进程），而无需依赖于任何操作系统 API。结合此技术与 SVEE VMM 获取的 Local-Booted OS 的内存信息，操作系统动态迁移管理器能够确定导致 Local-Booted OS 挂起或崩溃的进程，进而将这些信息自动记录到不兼容服务数据库。此后，在启动 SVEE 虚拟机前，操作系统动态迁移管理器将在 Local-Booted OS中自动禁用所有不兼容服务数据库中的服务。3.2.4 修改跟踪管理器为了满足约束 4（隔离程序执行效果的跟踪），SVEE 需要监视 Local-Booted
28、OS中的数据修改信息，为此本文引入了修改跟踪过滤驱动（Change Tracking Filter Driver，CTFD）以监视和记录文件的修改操作。而为了支持提交 Local-Booted OS中的修改结果到宿主操作系统，则需要同时在这两个操作系统中布署 CTFD。监视不同对象的修改信息需要实现不同的过滤驱动，如需要文件系统过滤驱动来实现对文件的监视，而对 Windows 注册表的监视则需要利用系统调用拦截技术。SVEE 运行结束时，可以向用户提供三种操作：放弃 SVEE 内隔离程序的执行结果、保留执行结果和提交执行结果到宿主操作系统。对于第一种情况，SVEE 虚拟机的整个运行环境将被销毁
29、，之后启动的 SVEE 虚拟机均需要重新创建新的虚拟简单磁盘；若保留执行结果，则仅关闭 SVEE 虚拟机，而不销毁虚拟简单磁盘；对于第三种情况，需要利用修改跟踪管理器来分析和比较 SVEE 虚拟机从创建到结束整个过程中 Local-Booted OS 和宿主操作系统的数据变化，进而进行修改合并，而合并的同时还需要解决可能发生的各种冲突。从安全的角度考虑，提交来源非可信软件的执行结果到宿主操作系统是不可取的，但对于质量非可信软件（不稳定代码和存在脆弱性代码）的执行结果而言还是有应用需求的。3.2.5 隐式操作系统信息重构组件为了满足约束 5（支持操作系统信息重构），SVEE 需要提供一种能够在虚
30、拟层获取操作系统语义信息的通用机制，包括进程、文件、网络、内存和注册表等关键的系统信息。由于客户操作系统的内部状态对虚拟机来说是完全透明的，因此隐式操作系统信息重构组件需要利用虚拟层有限的硬件视图信息，重构出操作系统的语义信息。为此，本文提出了一种新的隐式操作系统信息重构平台（Implicit OS Information Reconstruction Platform，IOIRP）。利用该技术，隐式操作系统信息重构组件能够在不借助操作系统 API 的情况下，利用硬件层的信息重构出操作系统的语义信息。第四章 隔离运行环境的功能完整性问题由于程序功能的正常执行与执行效果通常依赖于计算环境，尤其是
31、文件系统内容与操作系统配置等。因此，提升隔离运行环境的功能完整性需要在该环境内重现宿主操作系统的计算环境。本章将详细描述实现计算环境重现的基础本地虚拟化技术。为了解决在 SVEE 虚拟机中重用已有软件环境所带来的文件系统冲突和软硬件配置兼容性等问题，本章提出了基于卷快照的文件系统共享技术与操作系统动态迁移技术。测试结果表明卷快照技术带来的 I/O 性能下降小于 10%，处理器开销仅增加约3%，而动态迁移技术使得 SVEE 能够有效支持多种不同软硬件配置的计算机系统。由于目前个人计算平台下最普及的配置是微软的Windows操作系统与Intel的x86 处理器，因此，SVEE 首先在面向 x86
32、处理器的 Windows 平台下实现原型系统。4.1 基于卷快照的文件系统共享对于本地虚拟化技术而言，关键问题是如何直接使用宿主操作系统的安装映像。尽管 SVEE 虚拟机与宿主操作系统共享系统卷，但是这二者均不能感知彼此对系统卷数据的修改，这将导致 Loca-Booted OS 和宿主操作系统的文件系统数据与磁盘数据的冲突，进而使系统崩溃。解决此冲突的充要条件是这两个操作系统的文件系统对本系统内磁盘数据的修改均是封闭的，即不会影响另一个操作系统内的磁盘数据。为了给出此充要条件的形式化定义并为下一步的算法正确性分析做准备，首先定义了如下两个函数：函数 Write (OS, Block, t)：表
33、示时刻 t，操作系统 OS 的文件系统修改了该操作系统内的卷数据块 Block。函数的返回值即为写入的内容，若返回值为，则表示时刻 t 未修改数据块 Block。其中 OS Local-Booted OS, Host OS。函数 Read (OS, Block, t)：表示时刻 t，操作系统 OS 的文件系统读该操作系统内的卷数据块 Block，函数的返回值即为该数据块的内容。基于上述定义，充要条件可描述为：1. 若对 O S， B lock ， tt，有 Write (OS, Block, t)= ，则 Read (OS,Block, t)= Read (OS, Block, t)2. 若对
34、 O S， 彐B lock ， 彐tt，有 Write (OS, Block, t) ，则 Read (OS, Block, t)= Write (OS, Block, t), t=Maxt| Write (OS, Block, t)为了满足上述充要条件，SVEE 引入了卷快照技术。顾名思义，卷快照即为在快照创建时刻其对应的原始卷的一致性副本，一致性是通过写时复制（Copy-on-Write，COW）技术保存差异数据来保证的。利用这种机制，宿主操作系统（Host OS）修改的是原始卷，Local-Booted OS 修改的则是卷快照，因此 SVEE虚拟机解决了与宿主操作系统间由于写操作导致的数
35、据不一致问题。作为虚拟存储设备的实现基础，卷快照必须支持写操作。此外，它也必须能够由宿主操作系统的文件系统加载，也就是必须提供与文件系统标准卷一致的访问接口。此特性能够有效实现宿主操作系统内对卷快照内容的访问，从而支持快照导出到 SVEE 虚拟机前的文件配置、系统卷内硬件配置信息的修改等功能。图 1 快照驱动体系结构SVEE 的卷快照采用了 COW 机制，即在原始卷的数据被修改前复制该数据到特定的存储空间。本文称此存储区域为快照区域（Snapshots Area，SArea）。图 4.1 描述了在安装了卷快照驱动后的 Windows 设备驱动栈。如图所示，卷快照驱动在 Windows 设备对象
36、栈中位于其对应的原始卷设备对象之上，因此它能够有效地拦截写原始卷的请求并执行 COW 操作。该驱动创建了两类设备对象；一类是加载在原始卷设备对象（Original Volume Device Object）之上负责执行 COW操作的卷过滤设备对象（Volume Filter Device Object）；另一类是卷快照设备对象（Snapshot Volume Device Object），它负责向文件系统提供标准卷的访问接口，以便于被文件系统加载后用户可以访问快照数据，写快照的数据则被重定向到快照区域（SArea）。4.1.1 算法描述卷快照驱动的核心是处理操作系统对原始卷设备对象和卷快照设备
37、对象的读/写请求。其中，对原始卷设备对象的读操作最为直接，卷过滤设备对象直接将读原始卷的 I/O 请求包（I/O Request Package，IRP）发送给相应的原始卷，这是因为此操作不会影响原始卷设备对象和卷快照设备对象二者数据的一致性。卷快照驱动以基本块（Basic Block）为单位管理卷数据。它基于两个数据结构来管理 COW 操作的信息：一是快照位图表（Snapshot Bitmap Table），这个位图表每一比特位标识一个基本块是否已经被执行了 COW 操作，即已被备份到快照区域；另一个是原始卷基本块块号到对应快照区域基本块块号的映射，该映射以 AVL树结构组织信息，索引值为原
38、始卷基本块块号。Input: 原始卷设备对象，写原始卷的 IRPOutput: 无Method:1. if IRP 要写的原始卷的所有基本块都已被执行了 COW 操作（位图表中相应比特位均已经被置 1）2. 将该 IRP 直接转发到原始卷设备对象；3. else4. 挂起当前写原始卷的 IRP；5. for IRP 要写的原始卷的所有基本块6. if 当前原始卷基本块未被执行 COW 操作7. 构造新的读 IRP，参数为原始卷的当前基本块；8. 异步执行此 IRP，读取原始卷的当前基本块的内容，为备份做准备；9. 利用快照空间管理器提供的接口，从快照空间申请新的基本块；10. 构造新的写 IR
39、P，目标为快照空间的对应基本块；11. 异步执行此 IRP，将之前读取的原始卷的当前基本块的内容写入快 照空间的对应基本块，完成 COW 操作；12. 设置快照位图表中当前基本块对应的比特位；13. 将当前基本块及其对应的快照空间的基本块插入到 AVL 映射树中；14. end if15. 将挂起的写原始卷的 IRP 转发给下层的原始卷；16. end for17. 完成被挂起的 IRP;18. end ifEnd Algorithm 写原始卷的 IRP 的处理算法图 2 写原始卷的 IRP 的处理算法（COW 算法）为了突出主要流程，本章之后描述的算法均忽略了错误和异常处理，也没有标识出相应
40、的同步操作等。图4.2描述了卷过滤设备对象处理写原始卷IRP的算法。如算法所示，当截获写原始卷的 IRP 时，卷过滤设备对象将检查 IRP 的参数以判断将要修改的数据中是否存在未被复制备份的部分（第 1 行），存在则阻塞该 IRP（第 4 行）直到复制相应数据到 SArea 的操作完成（5-16 行），否则直接转发此IRP 到下层原始卷（第 2 行）。图 4.3 和图 4.4 分别描述了读/写卷快照设备对象的处理算法。如算法 4.3 所示，读卷快照设备对象时，将根据欲读取的基本块是否被执行了 COW 操作来判断该块对应的实际数据源是原始卷还是快照空间中的对应块（6-13 行）。算法 4.4 描
41、述的写卷快照设备对象的过程相对复杂，对于已经被执行了 COW 操作的基本块，可以直接写快照空间中的对应块；而对未被执行 COW 操作的基本块，则需要在快照空间中分配新的存储块，并复制原始卷中的对应内容到新分配的存储块中，之后才能写快照空间的这个新分配的存储块（8-17 行）。Input: 卷快照设备对象（简称为卷快照），读卷快照设备对象的 IRPOutput: 无Method:1. if IRP 要读的卷快照的所有基本块所对应的原始卷的那些基本块都未被执行了 COW 操作（快照位图表中相应比特位均为 0）2. 将该 IRP 直接转发到对应的原始卷设备对象；3. else4. 挂起当前读卷快照的
42、 IRP；5. for IRP 要读的卷快照的所有基本块6. if 当前卷快照基本块对应的原始卷的基本块已经被执行 COW 操作（通过查快照位图表）7. 根据当前块号在 AVL 映射树查找在快照空间中对应的基本块块号；8. 构造新的读 IRP，目标参数为快照空间中对应的基本块；9. 异步执行此 IRP；10. else11. 构造新的读 IRP，目标为当前卷快照基本块对应的原始卷的基本块；12. 异步执行此 IRP；13. end if14. end for15. 完成被挂起的 IRP;16. end ifEnd Algorithm 读卷快照设备对象的 IRP 处理算法图 4.3 读卷快照设备
43、对象的 IRP 处理算法Input: 卷快照设备对象（简称为卷快照），写卷快照设备对象的 IRPOutput: 无Method:1. 挂起当前写卷快照的 IRP；2. for IRP 要写的卷快照的所有基本块3. if 当前卷快照基本块对应的原始卷的基本块已经被执行 COW 操作（通过查快照位图表）4. 根据当前块号在 AVL 映射树查找在快照空间中对应的基本块块号；5. 构造新的写 IRP，目标参数为快照空间中对应的基本块；6. 异步执行此 IRP；7. else8. 利用快照空间管理器提供的接口，从快照空间申请新的基本块；9. if 当前要写的长度等于基本块10. 构造新的写 IRP，目标
44、为快照空间中新分配的基本块；11. 异步执行此 IRP；12. else （当前要写的长度小于基本块）13. 构造新的写 IRP，目标为当前块在原始卷中对应的基本块；14. 异步执行此 IRP；15. 合并从原始卷读取的内容到当前要写的内容（长度为一个基本块）；16. 构造新的写 IRP，目标为快照空间中新分配的基本块，写的内容为前一步内并的内容；17. 异步执行此 IRP；18. endif19. 设置快照位图表中当前基本块对应的比特位；20. 将当前基本块及其对应的快照空间的基本块插入到 AVL 映射树中；21. end if22. end if23. 完成被挂起的 IRP;End Alg
45、orithm 写卷快照设备对象的 IRP 处理算法图 4.4 写卷快照设备对象的 IRP 处理算法通过算法所述过程，卷快照设备对象向文件系统提供了标准卷的访问接口。因此，应用程序能够以操作通用卷的方式访问卷快照设备对象的数据。4.1.2 算法正确性分析结合卷快照设备对象的读/写算法与写原始卷的 COW 算法，现分析卷快照技术满足解决宿主操作系统与 Local-Booted OS 间数据不一致问题所需的充要条件，本节分别针对充要条件的两个部分进行了分析。1. 对 Block，tta) 对 Host OS 有 Write (Host OS, Block, t)= （此时 Block 表示的是原始卷
46、中的数据块）：此时若 Write (Local-Booted OS, Block, t)= ，则显然原始卷中 Block 块的数据不会改变，即 Read (Host OS, Block,t)= Read (Host OS, Block, t)；若 Write (Local-Booted OS, Block, t) ，由于算法 4.4（写卷快照设备对象的 IRP 处理算法）保证了将写操作重定位到 SArea 中，因此 Local-Booted OS 不会直接修改原始卷，此时原始卷中 Block 块的数据也不会改变，即 Read (Host OS,Block, t)= Read (Host OS,
47、 Block, t)。b) 对 Local-Booted OS 有 Write (Local-Booted OS, Block, t)= （此时Block 表示的是卷快照设备中的数据块）：此时若 Write (Host OS,Block, t)= ，则卷快照设备中 Block 块的数据是直接从原始卷中读取（算法 4.3，“读卷快照设备对象的 IRP 处理算法”的 1-2 行），因此 Read (Local-Booted OS, Block, t)= Read (Local-Booted OS, Block,t)；若 Write (Host OS, Block, t) ，由于算法 4.2（写原始
48、卷的 IRP的处理算法）通过 COW 操作保证了原始数据复制到 SArea 中，此后读快照设备均是读 SArea 中的备份数据，因此 Read (Local-Booted OS,Block, t)= Read (Local-Booted OS, Block, t)。2. 若对 Block，tta) 对 Host OS 有 Write (Host OS, Block, t) （此时 Block 表示的是原始卷中的数据块）：此时若 Write (Local-Booted OS, Block, t)= ，则显然原始卷中 Block 块的数据即为最后写入的数据，即 Read (Host OS, Block, t)=Write (Host OS, Block, t)，t=Maxt| Write (Host OS,Block, t) ；若 Write (Local-Booted OS, Block, t) ，由于算法 4.4（写卷快照设
