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, Blo

49、ck, t)=Write (Host OS, Block, t)，t=Maxt| Write (Host OS,Block, t) ；若 Write (Local-Booted OS, Block, t) ，由于算法 4.4（寫卷快照設備對象的 IRP 處理算法）保證了將寫操作重定位到 SArea 中，因此 Local-Booted OS 不會直接修改原始卷，此時原始卷中 Block 塊的數據也仍為最后寫入的數據，即 Read (Host OS,Block, t)=Write (Host OS, Block, t)，t=Maxt| Write (Host OS,Block, t) 。b) 對

50、Local-Booted OS 有 Write (Local-Booted OS, Block, t) （此時Block 表示的是卷快照設備中的數據塊），此時卷快照設備中 Block塊的數據是直接寫到 SArea（算法 4.4，“寫卷快照設備對象的 IRP 處理算法”），同時讀快照設備也是讀 SArea 中的相應塊，因此無論是Write (Host OS, Block, t)= 或 Write (Host OS, Block, t) ，均有Read (Local-Booted OS, Block, t)= Read (Local-Booted OS, Block, t)。綜上所述，卷快照技術保

51、證 SVEE 滿足了解決文件系統沖突所需的充要條件。4.1.3 算法復雜性分析如前所述，卷快照技術的COW操作增加了發送給原始卷的寫IRP的處理流程，因此創建了快照的原始卷的 I/O 性能將有所下降。為了定量分析 SVEE 的卷快照技術帶來的磁盤 I/O 性能下降，本文做了如下定義：函數 IoTime (Op, Target)： Op 定義了 I/O 操作類型，主要包括讀寫兩種操作，Target 表示 I/O 操作針對的卷，因此 IoTime 實際定義了讀寫卷 Target 某一數據塊BlockNo 所需的 I/O 時間。常量 TestTime：表示卷快照驅動判斷了指定邏輯塊是否已經進行了 C

52、OW 操作所需的時間。常量 LockBitmapTableTime：表示鎖/解鎖快照位圖表所需的時間。常量 LockMapTableTime：表示鎖/解鎖原始卷基本塊塊號到對應快照區域基本塊塊號的映射表所需的時間。常數 RTimetarget/WTimetarget分別定義了在創建快照前，直接讀/寫卷 target 的 I/O 時間。常數 BasicBlockSize：定義了 COW 基本塊的大小。函數 Confict (BlockNo，Target)：定義了讀卷 Target（原始卷或卷快照設備）的塊 BlockNo 時該塊正在執行寫操作的概率。函數 Dirty (BlockNo)：定義了原

53、始卷中塊 BlockNo 已執行了 COW 操作的概率。基于以上定義，可以用如下公式計算具有快照的原始卷的 I/O 時間（OV 表示原始卷，SA 表示快照空間，VS 表示卷快照）。由讀取原始卷的處理流程可得：IoTime (Read, OV) = LockBitmapTableTime + TestTime + RTimeOV+Confict (BlockNo，Target) x IoTime (Write, OV)其中 IoTime (Write, OV)定義了寫原始卷所需的時間，由算法 4.11（寫原始卷的 IRP 的處理算法，COW 算法）可得如下公式：IoTime (Write, OV

54、) = LockBitmapTableTime + TestTime + Dirty (BlockNo) x(LockMapTableTime+RTimeOV+WTimeSA)+WTimeOV此外，可以用如下公式計算讀/寫卷快照的 I/O 時間。利用函數 Dirty (BlockNo)，公式 4.3 和 4.4 可表示為：IoTime(Read,VS) = LockBitmapTableTime + TestTime + Dirty (BlockNo) x(RTimeSA+ LockMapTableTime ) + (1- Dirty (BlockNo) xRTimeOVIoTime(Writ

55、e,VS) = LockBitmapTableTime + LockMapTableTime + TestTime +WTimeSA+ Dirty (BlockNo) x LockMapTableTime + (1- Dirty(BlockNo) x RTimeOV 由于 TestTime 主要包括兩步計算操作和至多兩次訪存操作：首先執行右移操作計算讀寫地址所在邏輯塊的塊號，接著進行一次比特位比較操作（一般使用異或運算），這兩步運算均可在一個指令周期內完成。因此一般情況下，TestTime相對I/O讀寫操作所需時間可以忽略不計。與TestTime類似，LockBitmapTableTime和

56、LockTableTime 與 I/O 開銷相比也可忽略。此外，由于現有操作系統都支持重疊I/O 操作（Overlapped I/O），即公式（4.1）的 Confict (BlockNo，Target) x IoTime(Write, OV)這一項可以忽略不計。因此公式 4.1、4.2、4.5 和 4.6 可簡化為如下公式：IoTime (Read, OV) RTimeOVIoTime(Write,OV) Dirty(BlockNo) x (RTimeOV+WTimeSA)+WTimeOVIoTime(Read,VS) Dirty(BlockNo)xRTimeSA+(1- Dirty (Bl

57、ockNo) x RTimeOVIoTime(Write,VS) WTimeSA+(1- Dirty (BlockNo) x RTimeOV由簡化后的公式可知，SVEE 的卷快照技術給讀原始卷帶來的性能開銷可忽略，測試數據也證明了這一點。而對于給定長度 Length 的 I/O 操作，I/O 開銷如公式 4.11 所示：由 SVEE 卷快照算法（算法 4.2、4.3 和 4.4）可知，由于以基本塊（Basic Block）為單位管理卷數據，因此算法的內存空間開銷由 BasicBlockSize 和卷大小VolumeSize 確定。快照位圖表所占用空間如公式 4.12 所示（以字節為單位），而原

58、始卷基本塊塊號到對應快照區域基本塊塊號的映射表所占用的空間則如公式4.13 所示，其中 NodeSize 表示映射表中一個節點所占用的空間。如公式 4.11、4.12 和 4.13 所示，BasicBlockSize 越大，算法的內存空間開銷越小，COW 操作越少。但是，由于快照空間所占用的磁盤空間為 O(BasicBlockSize)，因此，隨著 BasicBlockSize 的增大，快照空間的空間開銷越大。通過測試，結果表明當基本塊大小為 256K 字節時，I/O 性能與磁盤空間開銷達到了比較好的平衡。4.1.4 算法優化由公式 4.8 和 4.10 可知，在保證 COW 算法正確性的前提下，減少 COW 操作可以有效提高寫原始卷和寫卷快照 I/O 性能