在上一講中我介紹了：Intel的VT（Virtual Technology）和AMD的AMD-V（AMD Virtualization）技術對X86架構處理器打了硬件補丁之後，X86平臺在虛擬CPU與內部存儲器方面變成了一個支持完全虛擬化的平臺，在這方面，Citrix Xen，MS Hyper-V（“在旁邊的虛擬化”）與VMware ESX（全虛擬化）之間的差別已不復存在。但我必須提醒：前兩者與後者在虛擬輸入輸出設備（IO Devices）方面仍然存在着一個根本的重要的差別。本講揭示這一差別。
與虛擬CPU和內存的情況一樣，虛擬一個IO設備也是讓一個虛擬機（VM）感覺到它是在獨享該設備。所以IO設備虛擬化任務也是替每一個VM分別管理好所用設備的服務狀態（service state）。設想當一個設備（如網卡）在某個時間片斷爲VM1提供了一個服務片斷（讀入一頁網頁），在下一個時間片斷要轉而向VM2提供服務時，此時系統就必須先記住該設備爲VM1提供當前服務片斷後的狀態，纔可以讓設備轉向服務於VM2。只有這樣做該設備纔會知道以後再回到VM1時怎樣繼續提供尚未完成的服務。因爲每一個IO設備都完全受控於一個叫做設備驅動器的軟件，所以對一個設備和一個VM之間進行狀態跟蹤管理也就是針對相應驅動軟件的服務狀態進行跟蹤管理。
“在旁邊的虛擬化”（Para-Virtualization, Citrix Xen與MS Hyper-V都是）採用了非常簡單實用的“在旁邊有驅動器”之方法：讓所有的客戶（guest）VM 都去使用安裝在那個“管理OS”（Xen的Dom0，Hyper-V的Parent Partition）裏面現成的設備驅動器。這樣一來整個平臺上的IO設備就可以步調一致井井有條地爲每一個客戶VM服務了。當一個客戶VM中的OS（中自有的設備驅動器）向硬件發出IO設備使用指令時，這些指令會被trap到hypervisor裏，再被轉到管理OS去使用它裏面相應的設備驅動器。
與這個方法不同，VMware ESX選擇在hypervisor裏面置入並管理平臺上所有的IO設備驅動器。ESX上的管理OS（又叫做Host OS或Service Console）只負責讓系統管理員來管理客戶VMs，比如創立、啓動客戶VM，啓動VMotion操作等等，而不負責虛擬任何IO驅動器。另外我們知道ESXi壓根就不帶有管理OS，系統管理員是通過網絡進入hypervisor來管理客戶VM的。
上回我還講道：Intel和AMD在給X86架構打硬件補丁的工作還實現了統一控制平臺上IO設備對內存的直接訪問（Direct Memory Access, DMA）。這改變了以前機器上IO設備可以隨意對主機內存進行直接訪問的無政府主義危險狀況。諸位不要以爲只有中央處理器（CPU）纔是平臺上唯一的腦子可以對內存進行訪問操作。CPU的確可以被看作是平臺上的“大腦”，然而平臺上還有諸多“小腦”們：幾乎每一個現代IO設備都自身帶有固件，裏面裝有可執行指令可對主機內存進行讀寫訪問。在以前的X86硬件上這些小腦們對主機內存進行DMA讀寫操作根本不必聽從大腦的指揮。幸虧在非虛擬情況下平臺上只跑一個操作系統，如果某個小腦對主機內存做了錯誤操作，造成的破壞也許還可以容忍，因爲大不了平臺崩潰只不過毀掉了跑在一臺機器上的應用（一定遇到過Windows的藍屏吧！）。如今在一個虛擬化的服務器平臺上跑着許多不同虛擬機和不同操作系統，無政府主義的危害就不再那麼單純無邪了。小腦的一個誤操作有可能打破不同虛擬機之間的隔離，輕者造成所模擬的操作系統出錯，重者導致平臺上所有的虛擬機全部崩潰。最近在X86硬件上的補丁工作（Intel的 VT-d, AMD的 IOMMU）對主板進行了重新佈線，將所有小腦們的IO連線都統一聯到北橋上的一個硬件部件IOMMU，於是大腦就可以使用該部件，採用MMU同樣的方法統一協調管理小腦們對內存的IO訪問了。有了大腦統一協調管理IOMMU，小腦即使誤操作也應該無法穿越不同VM之間的隔離。但是這個說法只適用於通常的非惡意系統軟硬件錯誤情形，不適用於在計算機安全上出錯的情形。在考慮安全問題時所謂錯誤都是惡意***的結果，是***者有意引入的。在考慮安全問題時小腦們的驅動器軟件（請回憶，IO設備都是受驅動器控制的）身處於系統軟件棧的哪個權限層次就是一個非常重要的問題。這些軟件所處的權限層次越接近硬件層，***者對它們進行***的手段就越有限也越困難。
對於“在旁邊的虛擬化”方法（ Citrix Xen與MS Hyper-V），前面我們說過所有設備驅動器軟件都安裝在管理OS裏面。這個管理OS雖然跑在一個低特權態（hypervisor之上的非內核態），卻由於需要向平臺上所有客戶VMs提供設備驅動器服務因而必須可以操控所有這些客戶VMs。於是這個處於低特權態的管理OS就自然形成了一個可以被利用來對任一客戶VM進行DMA***的最薄弱環節。所有對一般OS有效的***方法（我們知道有大量這樣的方法）都可以被利用來***這個OS中的驅動器軟件，對客戶VM實施DMA***。
而VMware ESX的情況不同：平臺上所有設備驅動器都是在hypervisor中模擬得到的。我們知道hypervisor是直接跑在硬件上的，即處於最高特權態。一般***OS的用戶態手段都不能對hypervisor產生有效***。另外Intel VT-d和AMD IOMMU都格外注重對hypervisor代碼與數據施加保護。如果想要通過***hypervisor中設備驅動器的方法來對客戶VM實施DMA***，那要遠比這些設備驅動器處身於用戶態OS中的情況困難得多。
業界諸多專家已經認可如下爲不爭事實：用可信計算技術來保護hypervisor是一個可行方法，Intel的Trusted eXecution Technology（TXT）就是一個典型案例。而用可信計算技術來保護用戶態OS是一個不可行方法，MS的Vista OS中的BitLocker技術就是嘗試這一方法的一個典型失敗案例。
下一講將介紹可信計算技術並討論爲什麼使用可信計算技術來保護hypervisor，尤其是保護象VMware ESX那種自身含有IO設備驅動器的hypervisor，這種技術方法可以在雲計算或基於服務架構的安全保護上找到重要有效的應用。