張　擂　李清寶　馮培鈞　周登元

(解放軍信息工程大學　河南 鄭州 450000) (數(shù)學工程與先進計算國家重點實驗室　河南 鄭州 450000)

?

基于VMM的Windows文件系統(tǒng)監(jiān)控

張擂李清寶馮培鈞周登元

(解放軍信息工程大學河南 鄭州 450000) (數(shù)學工程與先進計算國家重點實驗室河南 鄭州 450000)

摘要文件系統(tǒng)監(jiān)控是文件保護的基礎。針對現(xiàn)有文件系統(tǒng)監(jiān)控容易被惡意軟件破壞的問題，提出一種基于VMM的Windows文件系統(tǒng)監(jiān)控方法。該方法利用硬件虛擬化技術，通過監(jiān)控系統(tǒng)調用監(jiān)控文件系統(tǒng)操作，且監(jiān)控手段對客戶系統(tǒng)透明，保證實施的監(jiān)控安全可信。最后設計并實現(xiàn)了相應的原型系統(tǒng)，同時對原型系統(tǒng)的監(jiān)控效果和時間開銷進行測試。實驗結果表明，原型系統(tǒng)能夠監(jiān)控常見的Windows文件系統(tǒng)操作，并且時間開銷在可接受的范圍內。

關鍵詞文件系統(tǒng)監(jiān)控VMM文件保護

0引言

文件在操作系統(tǒng)的各類功能中都充當著十分重要的角色，如可執(zhí)行文件決定著系統(tǒng)行為；文檔文件保存著用戶信息；配置文件決定著系統(tǒng)狀態(tài)。攻擊者常將文件作為攻擊目標或攻擊文件以輔助進行其他攻擊，如篡改可執(zhí)行文件以實現(xiàn)對系統(tǒng)的控制；篡改配置文件從而關閉系統(tǒng)的保護功能；篡改文檔文件來影響用戶決策等。文件保護是保護計算機系統(tǒng)的必要功能，系統(tǒng)內的文件通過文件系統(tǒng)管理，故文件系統(tǒng)監(jiān)控更是文件保護的基礎。

近幾年，針對文件的攻擊呈增長趨勢，造成了嚴重的經(jīng)濟損失和信任危機，給企業(yè)運行和公眾生活造成了重大影響。文件保護的嚴峻形勢表明傳統(tǒng)文件系統(tǒng)監(jiān)控[1-3]不足以應對最新的威脅。傳統(tǒng)文件系統(tǒng)監(jiān)控大多使用API HOOK[1]、SSDT HOOK[1]、文件系統(tǒng)過濾驅動[2]和文件系統(tǒng)微過濾驅動[3]實現(xiàn)，這些監(jiān)控方法和攻擊手段位于同一特權級或更低特權級，導致攻擊者可以繞過或破壞對文件系統(tǒng)實施的監(jiān)控。虛擬機監(jiān)控器VMM(Virtual Machine Monitor)位于客戶操作系統(tǒng)和硬件之間，相對客戶操作系統(tǒng)擁有更高的特權，故基于VMM的監(jiān)控文件系統(tǒng)是解決現(xiàn)有威脅的一個重要思路。傳統(tǒng)基于軟件實現(xiàn)的VMM性能開銷太大，但較新的CPU都提供了對硬件虛擬化的支持，硬件虛擬化技術能夠使VMM的性能開銷大幅降低。本文利用Intel系列CPU提供的硬件虛擬化機制，基于開源項目NewBluePill，實現(xiàn)無法被用戶層或內核層中的惡意軟件破壞的Windows文件系統(tǒng)監(jiān)控。

1硬件虛擬化技術與NewBluePill

硬件虛擬化技術主要有Intel-VT和AMD-V兩種，這兩種技術的設計原則類似。本文基于Intel-VT技術。VT技術引入新的指令和運行模式，VMM位于VMX root模式，客戶系統(tǒng)位于VMX non-root模式。兩種模式的轉換過程如圖1所示，VMXON指令和VMXOFF指令分別用于開啟和關閉VMM。開啟VMM后，VMM通過VMLAUNCH啟動客戶系統(tǒng)。在客戶系統(tǒng)的運行過程中，當執(zhí)行到某些指令或遇到某些事件時，觸發(fā)#VMEXIT事件從而陷入VMM，位于root模式的VMM獲得控制。VMM執(zhí)行對陷入事件的處理后，通過VMRESUME指令恢復客戶系統(tǒng)的執(zhí)行。

圖1　VT技術模式轉換過程

觸發(fā)#VMEXIT事件的指令和事件分為無條件和有條件兩類。無條件觸發(fā)包括如CPUID、GETSEC等指令，執(zhí)行這些指令會立刻陷入VMM，此時觸發(fā)#VMEXIT事件的指令并沒有執(zhí)行，系統(tǒng)狀態(tài)為該指令執(zhí)行前的狀態(tài)。其他觸發(fā)#VMEXIT事件的指令和所有觸發(fā)#VMEXIT事件的事件都屬于有條件陷入，攔截這些指令和事件需要對虛擬機控制結構VMCS(Virtual-Machine Control Structure)進行相應的配置。基于VT技術實現(xiàn)VMM時，會有一個事件分發(fā)函數(shù)作為#VMEXIT事件處理的入口，VMCS中的VM_EXIT_REASON成員保存每次觸發(fā)#VMEXIT事件的原因。

Intel-VT技術經(jīng)過多年的發(fā)展已經(jīng)歷了幾個版本，從VT-X起引入了新的地址翻譯機制擴展頁表EPT(Extended Page Table)。該機制在原有虛擬地址到物理地址的翻譯機制之上增加一層新的地址翻譯機制，開啟EPT機制之后，原有的物理地址變成客戶物理地址，客戶物理地址和物理內存不再對應，客戶物理地址需要由VMM利用EPT機制翻譯成主機物理地址，主機物理地址可以用于訪問物理內存。EPT的地址翻譯過程和數(shù)據(jù)結構與虛擬內存機制類似，EPT的頂級頁表地址保存在VMCS中。

NewBluePill項目誕生于2007年，由Invisible Things Lab開發(fā)，現(xiàn)在對外公開的版本是NBP-0.32-public版本。該項目能夠在系統(tǒng)運行過程中動態(tài)加載和卸載，并且使用自己的頁表，在操作系統(tǒng)中無法看到NewBluePill占用的內存。最重要的是NewBluePill僅支持一個客戶VM，不包含VM間同步、IO虛擬化等不需要的功能，適合對單個系統(tǒng)進行監(jiān)控。NewBluePill同時支持Intel-VT和AMD-V兩種虛擬化技術，本文基于Intel-VT技術。VT技術下，NewBluePill定義的#VMEXIT事件處理入口函數(shù)為VmxVmexitHandler，該函數(shù)負責客戶系統(tǒng)現(xiàn)場的保存與恢復，并調用下一級處理函數(shù)HvmEventCallback。HvmEventCallback調用VmxDispatchEvent，然后根據(jù)VM_EXIT_REASON調用相應的事件處理函數(shù)。

2基于VMM的文件系統(tǒng)監(jiān)控

監(jiān)控文件系統(tǒng)的關鍵是監(jiān)控各種文件系統(tǒng)操作，通過對Windows文件的系統(tǒng)分析，總結出常用的文件系統(tǒng)操作包括：新建文件、新建目錄、刪除文件、刪除目錄、重命名文件、重命名目錄、打開文件、關閉文件、讀文件、寫文件、修改文件屬性、修改目錄屬性。本文通過對這些常用文件系統(tǒng)操作進行全面監(jiān)控，保證對文件系統(tǒng)進行監(jiān)控的全面性。

2.1文件系統(tǒng)操作監(jiān)控

在VMM中監(jiān)控文件系統(tǒng)操作，需要文件系統(tǒng)操作觸發(fā)#VMEXIT事件從而陷入VMM。但是Intel-VT技術沒有提供使文件系統(tǒng)操作陷入VMM的機制，所以需要使用虛擬機內省VMI(Virtual Machine Introspection)技術使文件系統(tǒng)操作陷入VMM。通過對上述文件系統(tǒng)操作進行調試跟蹤，結果表明上述操作都通過系統(tǒng)調用實現(xiàn)其功能，如表1所示。

表1　文件系統(tǒng)操作和系統(tǒng)調用對應關系

從表1可以看出，重命名等多個文件系統(tǒng)操作都通過NtSetInformationFile系統(tǒng)調用實現(xiàn)。在截獲到系統(tǒng)調用NtSetInformationFile后，需要進一步分析此次攔截的系統(tǒng)調用所對應的文件系統(tǒng)操作。調試分析的結果表明該系統(tǒng)調用的第三個參數(shù)可以用來區(qū)分不同的文件系統(tǒng)操作。所以只要實現(xiàn)了基于VMM的監(jiān)控系統(tǒng)調用，就可以基于VMM分別監(jiān)控上述文件系統(tǒng)操作。

2.2基于VMM的系統(tǒng)調用監(jiān)控

系統(tǒng)調用是處理器提供的在用戶模式調用內核模式功能的機制，較新的Intel處理器同時支持三種系統(tǒng)調用機制，Windows操作系統(tǒng)在不同的處理器模式使用不同的系統(tǒng)調用機制，本文對這三種機制都進行監(jiān)控。

2.2.1基于中斷處理的系統(tǒng)調用

最早的系統(tǒng)調用通過軟中斷的方式實現(xiàn)，在中斷向量表的第0x80項保存系統(tǒng)調用入口函數(shù)，應用層的代碼通過INT 80H指令執(zhí)行系統(tǒng)調用。

文獻[6]重寫中斷描述符表中的中斷處理函數(shù)指針，使其指向未分配物理內存的虛擬地址。當執(zhí)行系統(tǒng)調用時會發(fā)生缺頁PF(Page Fault)異常，對VMCS進行正確的配置可以導致PF異常陷入VMM，隨后在VMM中判斷導致PF異常的指令是否為INT 80H，從而實現(xiàn)監(jiān)控INT 80H方式的系統(tǒng)調用。這種監(jiān)控方式存在一大不足，即位于內核層的攻擊者可以發(fā)現(xiàn)0x80項中斷服務的處理函數(shù)指針并非指向中斷服務處理函數(shù)，從而發(fā)現(xiàn)VMM的存在，攻擊者進而可以將其改回原值或改為惡意函數(shù)。文獻[5]修改IDTR中的IDT表大小，導致通過INT方式觸發(fā)超過最大值的中斷時產(chǎn)生通常保護GP(general protection)異常。由于要監(jiān)控0x80號中斷，所以可以設置的IDTR最大值為0x7F。這種監(jiān)控方式有兩個不足：首先這種方式使得大于0x7F的INT中斷都陷入VMM，而陷入VMM是一個開銷十分大的操作，這導致了大量無關時間開銷；其次這種方式也對客戶操作系統(tǒng)非透明，位于內核的攻擊者可以發(fā)現(xiàn)IDTR的大小存在異常，并可以方便地將其改回0xFF。文獻[4]將中斷處理函數(shù)的入口指令改為VMMCALL指令，從而使INT 80H中斷陷入VMM。這種方法同樣存在對客戶系統(tǒng)不透明的問題，攻擊者可以發(fā)現(xiàn)保護所做的修改并可以破壞實施的保護。文獻[8]仿照文獻[6]的思路，通過影子頁表保證監(jiān)控的透明性。文獻[8]不直接修改IDT中服務函數(shù)的地址，而是修改服務函數(shù)地址在影子頁表中的表項，通過第二級地址翻譯過程將其指向一個非法地址，從而引發(fā)PF異常。位于內核層的攻擊者通過讀IDT表中的表項只能得到合法的處理函數(shù)地址，所以無法發(fā)現(xiàn)監(jiān)控的存在。

考慮上述監(jiān)控方法存在的時間開銷和透明性問題，本文借鑒文獻[8]的研究，使用EPT頁表代替影子頁表來實現(xiàn)第二級地址翻譯。首先修改NewBluePill的初始化函數(shù)，為EPT頁表分配空間，并在客戶物理地址和主機物理地址間建立映射關系，此時建立的映射關系使客戶物理地址A映射到同一主機物理地址A。然后修改EPT頁表中0x80項中斷處理函數(shù)地址的頁表項，將其改為不存在物理內存的主機物理地址。最后修改NewBluePill的VMCS初始化函數(shù)，在其中開啟EPT機制，并配置好頂級EPT頁目錄。相比文獻[8]的研究，使用硬件提供的EPT機制有更好的時間效率。

2.2.2SYSENTER快速系統(tǒng)調用

SYSENTER是Intel系列CPU提供的快速系統(tǒng)調用機制，它借助模式專用寄存器MSR(Model Specific Register)省去系統(tǒng)調用過程中的權限檢查和內存訪問操作，減少了系統(tǒng)調用的時間開銷。使用SYSENTER指令發(fā)起系統(tǒng)調用時，RIP的值來自于IA32_SYSENTER_EIP，RSP的值來自于IA32_SYSENTER_ESP，CS的段選擇子來自于IA32_SYSENTER_CS的0到15位，SS的段選擇子為CS的段選擇子加8，并且CS和SS寄存器的不可見部分不由段描述符表獲得，而由硬編碼直接賦值。

文獻[4]利用無條件陷入VMM的VMMCALL指令，將IA32_SYSENTER_EIP所指地址處的指令改為VMMCALL指令，使攻擊者通過SYSENTER指令進入內核時立刻陷入VMM。但這種方法存在對客戶系統(tǒng)不透明的問題，攻擊者可以發(fā)現(xiàn)監(jiān)控功能對系統(tǒng)的修改并可以進一步破壞實施的監(jiān)控。文獻[7]重寫MSR寄存器IA32_SYSENTER_EIP的內容，將其改為一個未分配物理內存的虛擬地址。當系統(tǒng)執(zhí)行SYSENTER指令時會引起PF異常，通過配置VMCS可以使PF異常陷入VMM。在VMM對PF異常的處理過程中判斷引發(fā)PF異常的指令是否為SYSENTER，實現(xiàn)對SYSENTER的監(jiān)控。文獻[5]修改IA32_SYSENTER_CS為全0，使SYSENTER指令產(chǎn)生GP異常，然后在VMM中監(jiān)控GP異常。根據(jù)Intel指令手冊，SYSENTER指令產(chǎn)生GP異常時指令的其他功能都沒有執(zhí)行，所以需要在VMM中修改客戶機狀態(tài)來模擬SYSENTER指令的全部功能。這種方法同樣影響SYSRET指令，所以需要在陷入VMM之后根據(jù)觸發(fā)#VMEXIT事件的指令來進一步區(qū)分，并且對SYSRET指令的功能進行模擬。

文獻[7]和文獻[5]都通過修改MSR寄存器實現(xiàn)，但是文獻[7]截獲的是PF異常，PF異常在系統(tǒng)中出現(xiàn)頻率很高，導致系統(tǒng)陷入VMM的頻率很高，對系統(tǒng)影響很大。文獻[5]截獲的是GP異常，該異常在系統(tǒng)正常運行的過程中幾乎不會出現(xiàn)，陷入VMM的頻率非常低，所以本文參考文獻[5]的方法監(jiān)控通過SYSENTER指令的系統(tǒng)調用。

本文首先修改NewBluePill初始化VMCS的過程，修改其中對異常位圖的初始化，使GP異常觸發(fā)VMEXIT事件。然后在NewBluePill中注冊處理因異常所觸發(fā)VMEXIT事件的事件處理函數(shù)，并在該函數(shù)中模擬SYSENTER和SYSRET指令的功能。最后修改NewBluePill的初始化函數(shù)，在初始化工作的末尾對IA32_SYSENTER_CS進行修改，將其改為全0。SYSENTER通過內部電路獲得MSR內容而不是RDMSR指令，所以本文在VMM中對RDMSR指令進行監(jiān)控。如果讀取的MSR是被修改的，則返回原來的正確值，這樣可以在不影響SYSENTER指令的同時保證客戶系統(tǒng)無法發(fā)現(xiàn)MSR寄存器被修改，實現(xiàn)透明監(jiān)控。

2.2.3SYSCALL快速系統(tǒng)調用

SYSCALL也是Intel系列CPU提供的快速系統(tǒng)調用機制，但它只支持64位模式，64位Windows操作系統(tǒng)在切換到64位模式后都使用該系統(tǒng)調用機制。由于它僅支持64位模式，所以它相對于SYSENTER還省去了CPU模式檢查的功能。此外，SYSCALL不修改RSP，需要進入內核后系統(tǒng)調用處理函數(shù)負責切換RSP。使用SYSCALL指令發(fā)起系統(tǒng)調用時，RIP的值來自于IA32_LSTAR， CS的段選擇子來自于IA32_STAR的32到47位，SS的段選擇子為CS的段選擇子加8，并且CS和SS寄存器的不可見部分也不由段描述符表獲得，而是由硬編碼直接賦值。

文獻[4]將IA32_LSTAR處的指令改為VMALL指令，從而使攻擊者通過SYSCALL指令進入內核時陷入VMM。但這種方法存在對客戶系統(tǒng)不透明的問題，攻擊者可以發(fā)現(xiàn)所做的修改并可以破壞實施的監(jiān)控。文獻[6]通過修改IA32_LSTAR為未分配物理內存的虛擬地址，當系統(tǒng)執(zhí)行SYSCALL指令時會引起PF異常，通過配置VMCS可以使該異常陷入VMM。文獻[5]修改IA32_EFER的SCE位為0，使系統(tǒng)不支持SYSCALL和SYSEXIT指令，導致通過SYSCALL指令執(zhí)行系統(tǒng)調用時會產(chǎn)生未定義指令UD(Undefined Instruction)異常，通過配置VMCS可以使UD異常陷入VMM。

文獻[6]和文獻[5]的方法都通過修改MSR實現(xiàn)，但文獻[6]的方法攔截的是PF異常。根據(jù)前文的分析可知，這種方法陷入VMM太頻繁，對系統(tǒng)性能影響太大。文獻[5]的方法只影響SYSCALL和SYSEXIT兩條指令，沒有不必要的陷入，故本文采用文獻[5]的方法監(jiān)控通過SYSCALL機制的系統(tǒng)調用。

由于UD異常產(chǎn)生于SYSCALL和SYSEXIT功能的最初階段，所以產(chǎn)生UD異常時指令的其他功能都沒有執(zhí)行，需要在VMM中對SYSCALL和SYSEXIT指令的功能進行模擬。本文首先修改NewBluePill初始化VMCS的過程，修改其中對異常位圖的初始化，使UD異常觸發(fā)VMEXIT事件。然后在NewBluePill中注冊處理因異常所觸發(fā)VMEXIT事件的事件處理函數(shù)，并在該函數(shù)中模擬SYSCALL和SYSEXIT指令的功能。最后修改NewBluePill的初始化函數(shù)，在初始化工作的末尾修改IA32_EFER的SCE位為0。由于該方法也通過修改MSR實現(xiàn)，破壞了監(jiān)控的透明性，故采用同SYSENTER快速系統(tǒng)調用相同的處理方法保證監(jiān)控的透明性。

2.3系統(tǒng)調用參數(shù)解析

實現(xiàn)了基于VMM監(jiān)控系統(tǒng)調用，也就實現(xiàn)了基于VMM監(jiān)控文件系統(tǒng)操作，從而實現(xiàn)了基于VMM監(jiān)控文件系統(tǒng)。但是監(jiān)控文件系統(tǒng)的目的是保護文件，由于系統(tǒng)內的不同文件往往有不同的保護需求，所以需要在監(jiān)控到文件系統(tǒng)操作對應的系統(tǒng)調用后解析出此次操作的文件路徑。根據(jù)解析文件路徑的方式可以將上述系統(tǒng)調用分為兩類：一類參數(shù)中包含操作對象的完整路徑，一類參數(shù)中包含操作對象的文件句柄。

NtCreateFile、NtOpenFile和NtDeleteFile都包含一個類型為POBJECT_ATTRIBUTES的參數(shù)，它是一個指針類型，指向一個OBJECT_ATTRIBUTES類型的對象。該對象的第三個成員ObjectName為指向一個UNICODE_STRING對象的指針，該UNICODE_STRING對象中的第三個參數(shù)指向的UNICODE字符串就是完整文件路徑。解析過程中需要注意兩點：一是在64位Windows系統(tǒng)中指針按照8字節(jié)對齊存放，UNICODE_STRING結構的前兩個參數(shù)為雙字節(jié)長度，所以第二個參數(shù)之后空四個字節(jié)才是第三個參數(shù)的內容；二是64位Windows系統(tǒng)默認通過RCX、RDX、R8、R9傳遞前四個參數(shù)，但通過SYSCALL指令剛進入內核的系統(tǒng)調用分發(fā)函數(shù)時，第三個參數(shù)不在R8中而在R10中，系統(tǒng)調用分發(fā)函數(shù)負責將R10中的參數(shù)移動到R8中，所以在監(jiān)控到SYSCALL系統(tǒng)調用時應該在R10中獲得所需要的參數(shù)。其過程如圖2所示。

NtReadFile、NtReadFileScatter、NtClose、NtWriteFile、NtWriteFileGather和NtSetInformationFile通過參數(shù)中的文件句柄確定操作的文件。截獲到這些系統(tǒng)調用后，需要通過文件句柄獲得對應的文件完整路徑。本文利用Windows提供的函數(shù)通過句柄獲得文件路徑，首先使用ObReferenceObjectByHandle函數(shù)獲得句柄對應的文件對象，然后使用IoQueryFileDosDeviceName獲得文件的完整路徑，其過程如圖3所示。

圖2　第一類參數(shù)解析過程　　圖3　第二類參數(shù)解析過程

3性能分析

3.1原型系統(tǒng)

本文的實驗環(huán)境是Window 7 SP1 X64系統(tǒng)。為了對文件系統(tǒng)監(jiān)控的效果和開銷進行測試，本文實現(xiàn)了一個文件系統(tǒng)監(jiān)控原型系統(tǒng)，原型系統(tǒng)架構如圖4所示。

圖4　測試系統(tǒng)架構

系統(tǒng)調用監(jiān)控模塊使用上文描述的監(jiān)控方法對系統(tǒng)調用進行監(jiān)控，文件系統(tǒng)操作執(zhí)行系統(tǒng)調用時陷入VMM。VMM中的系統(tǒng)調用監(jiān)控模塊截獲到文件系統(tǒng)操作對應的系統(tǒng)調用后，調用文件路徑解析模塊解析出此次操作文件的路徑，進一步可以根據(jù)文件路徑?jīng)Q定是繼續(xù)執(zhí)行文件系統(tǒng)操作還是阻止文件系統(tǒng)操作直接返回錯誤。

3.2文件系統(tǒng)監(jiān)控效果測試

3.2.1監(jiān)控有效性測試

本節(jié)對原型系統(tǒng)監(jiān)控文件系統(tǒng)的有效性進行測試，測試原型系統(tǒng)是否能夠監(jiān)控到上文列出的文件系統(tǒng)操作。

首先測試針對文件的文件系統(tǒng)操作。本文在原型系統(tǒng)的系統(tǒng)調用監(jiān)控模塊中實現(xiàn)對文件操作的各種監(jiān)控，使之阻止對文件的各類文件系統(tǒng)操作。測試結果如表2所示。

表2　監(jiān)控針對文件的文件系統(tǒng)操作效果

從測試結果可以看出，原型系統(tǒng)對上文列出的文件系統(tǒng)操作都成功實施了監(jiān)控，并可以根據(jù)需要阻止針對特定文件的操作。接下來測試目錄下的文件系統(tǒng)操作，采用上述相同的測試方法，阻止目錄下的各類文件系統(tǒng)操作。測試結果如表3所示。

表3　監(jiān)控目錄下的文件系統(tǒng)操作效果

從測試結果可以看出，原型系統(tǒng)對上文列出的目錄下的文件系統(tǒng)操作都成功實施了監(jiān)控，并可以根據(jù)需要阻止特定目錄下的文件系統(tǒng)操作。

3.2.2監(jiān)控透明性測試

本節(jié)對監(jiān)控的透明性進行測試，測試原型系統(tǒng)是否對客戶系統(tǒng)透明。原型系統(tǒng)主要修改兩個位置：一是EPT頁表，二是MSR寄存器。

EPT頁表位于VMM中。本文借鑒NewBluePill的思想。NewBluePill使用兩個頁表，一個客戶系統(tǒng)使用一個VMM使用，修改客戶系統(tǒng)的頁表項將VMM使用的虛擬地址都重定向到無關物理地址，從而使客戶系統(tǒng)無法訪問VMM的內容。本文使用EPT機制，但采用同樣的思想使VMM的內容對客戶系統(tǒng)透明。由于客戶系統(tǒng)無法訪問EPT內容，所以客戶系統(tǒng)無法得知80H號中斷處理函數(shù)的地址未分配物理內存。

Intel處理器規(guī)定系統(tǒng)只能通過RDMSR指令獲得MSR內容。透明性測試以IA32_EFER為例，監(jiān)控SYSCALL指令需要修改它。開啟原型系統(tǒng)前，使用RDMSR指令獲得IA32_EFER的內容為0xd01。開啟原型系統(tǒng)后，使用WRMSR指令將IA32_EFER內容改為0xd00，但通過RDMSR指令在客戶系統(tǒng)中獲得IA32_EFER的內容還是0xd01，在VMM中已可以監(jiān)控到由SYSCALL指令產(chǎn)生的UD異常。

3.3時間開銷測試

本節(jié)對監(jiān)控的時間開銷進行測試。測試時間開銷時文件系統(tǒng)監(jiān)控模塊不阻止任何操作，即測試正常處理的時間開銷。考慮到系統(tǒng)運行的時間可能會被許多情況影響，本文對每個測試項測量10次取平均值。

首先對INT 80H、SYSETER、SYSRET、SYSCALL和SYSEXIT這五條陷入VMM的指令進行單獨測試，測試分為對文件系統(tǒng)相關系統(tǒng)調用和文件系統(tǒng)無關系統(tǒng)調用進行。對文件系統(tǒng)無關系統(tǒng)調用的測試結果如表4所示。

表4　對于文件系統(tǒng)無關系統(tǒng)調用，陷入

從測試結果可以看出，對文件系統(tǒng)無關的系統(tǒng)調用，原型系統(tǒng)為系統(tǒng)調用相關的指令引入了10倍左右的時間開銷。引入這么多時間開銷主要是因為陷入VMM本身就是一件時間開銷很大的事件。但這僅為陷入指令的開銷，若考慮整個系統(tǒng)調用過程，這些時間開銷就微不足道了。例如COPYFILE命令的執(zhí)行時間為47 100 μs，系統(tǒng)調用指令增加的時間不到其十分之一。對文件系統(tǒng)相關系統(tǒng)調用的測試結果如表5所示。

表5　對于文件系統(tǒng)相關系統(tǒng)調用，陷入

陷入VMM后，根據(jù)解析參數(shù)的方式不同執(zhí)行的時間會有不同，以上以NtOpenFile和NtReadFile測試為例。這兩個系統(tǒng)調用分別代表兩類不同的參數(shù)解析方式，其中NtOpenFile的參數(shù)中包含路徑，NtReadFile的參數(shù)中僅包含文件句柄。從測試數(shù)據(jù)可以看出，NtOpenFile引入最高17倍的時間開銷，NtReadFile引入最高35倍的時間開銷，這主要是因為依據(jù)句柄解析路徑需要消耗更多的時間。并且從數(shù)據(jù)中可以看出，根據(jù)句柄解析路徑的時間相比從參數(shù)中直接獲得路徑增加的絕對時間為1500 μs左右。從數(shù)據(jù)可知，該方法為引起陷入的指令引入了大量的時間開銷，但考慮整個文件系統(tǒng)操作處理過程，引入的開銷影響就弱化了，如表6所示。

表6　文件系統(tǒng)操作時間開銷測試結果　　　單位：μs

上述數(shù)據(jù)以通過SYSCALL指令的系統(tǒng)調用機制為基礎。從測試數(shù)據(jù)可以看出，對于整個文件系統(tǒng)操作處理過程，原型系統(tǒng)增加的相對時間開銷都在可以接受的范圍內。從數(shù)據(jù)中還發(fā)現(xiàn)，對于文件系統(tǒng)操作，原型系統(tǒng)增加的絕對時間開銷大于陷入指令增加的絕對時間開銷，這是由于一個文件系統(tǒng)操作往往涉及多個系統(tǒng)調用，會多次陷入VMM。

4結語

本文在分析硬件虛擬化機制和Windows文件系統(tǒng)的基礎上，利用虛擬機內省技術，提出了一個基于VMM的Windows文件系統(tǒng)監(jiān)控方法。最后實現(xiàn)了一個文件系統(tǒng)監(jiān)控原型系統(tǒng)，并對原型系統(tǒng)的保護效果和時間開銷進行測試和分析。利用上文提出的方法可以在VMM中對常用文件系統(tǒng)操作進行監(jiān)控，但對存在快捷方式、文件鏈接的情況需要進一步研究。

參考文獻

[1] 張連成.主機主動入侵防御系統(tǒng)的研究與實現(xiàn)[D].解放軍信息工程大學,2007.

[2] 范學斌.一種新型文件安全控制系統(tǒng)模型[D].解放軍信息工程大學,2012.

[3] 張立建.Windows內核關鍵技術研究及其在內網(wǎng)安全中的應用[D].北京郵電大學,2013.

[4] Belay A,Bittau A,Mashtizadeh A J,et al.Dune:Safe User-level Access to Privileged CPU Features[C].OSDI,2012.2012:335-348.

[5] Pfoh J,Schneider C,Eckert C.Nitro:Hardware-based system call tracing for virtual machines[M].Advances in Information and Computer Security,Springer,2011:96-112.

[6] 李博,李建欣,胡春明,等.基于VMM層系統(tǒng)調用分析的軟件完整性驗證[J].計算機研究與發(fā)展,2011,48(8):1438-1446.

[7] Dinaburg A,Royal P,Sharif M,et al.Ether:malware analysis via hardware virtualization extensions[C]//Proceedings of the 15th ACM conference on Computer and communications security,2008.ACM,2008:51-62.

[8] 彭華,周安民,劉亮,等.基于虛擬機架構的文件系統(tǒng)監(jiān)控[J].信息安全與通信保密,2012(7):108-110.

[9] 王曉娣.基于虛擬機架構的惡意行為跟蹤系統(tǒng)[D].華中科技大學,2013.

收稿日期：2015-03-01。國家核高基科技重大專項(2013JH00103-04)；信息工程大學未來基金項目(1201)；數(shù)學工程與先進計算國家重點實驗室開放課題(2013A11)。張擂，碩士生，主研領域：信息安全與可信計算。李清寶，教授。馮培鈞，碩士生。周登元，碩士生。

中圖分類號TP309

文獻標識碼A

DOI:10.3969/j.issn.1000-386x.2016.07.067

WINDOWS FILE SYSTEM MONITORING BASED ON VMM

Zhang LeiLi QingbaoFeng PeijunZhou Dengyuan

(PLAInformationEngineeringUniversity,Zhengzhou450000,Henan,China) (StateKeyLaboratoryofMathematicalEngineeringandAdvancedComputing,Zhengzhou450000,Henan,China)

AbstractFile system monitoring is the foundation of file protection. In view of the problem that existing file system monitoring is easily destroyed by malware, this paper puts forward a VMM-based method to monitor Windows file system. The method uses hardware virtualisation technology and monitors the file system operation through monitoring system call. The implemented monitoring is guaranteed to be secure and trusted because it is transparent to clients. Corresponding prototype system is designed and implemented, at the same time the monitoring effect and time overhead of the prototype system are tested. Experimental results show that the prototype system can monitor the operations of common Windows file system, and the time overhead is within the acceptable range.

KeywordsFile system monitoringVirtual machine monitor (VMM)File protection