一種適用于智能設(shè)備的多重操作系統(tǒng)架構(gòu)＊

韓 威，陳 渝，劉迎莉，張久鋒

（1.清華大學(xué)計算機(jī)系，北京100088；2.總參第61研究所，北京100039；3.65049部隊，遼寧大連116100）

1 引言

近幾年，智能手機(jī)、平板電腦等移動智能設(shè)備越來越普及，其信息安全問題逐漸顯現(xiàn)并引起了人們的高度重視。虛擬化技術(shù)［1］是一種提高信息安全性的有效手段，針對移動智能設(shè)備的虛擬化研究成為當(dāng)前操作系統(tǒng)領(lǐng)域的一個熱點［2～4］。這些研究主要圍繞如何提高信息安全性與降低虛擬化開銷兩條主線展開。通過虛擬化技術(shù)，移動智能設(shè)備可以像服務(wù)器一樣運行多個操作系統(tǒng)實例，實例間相互隔離，提高了信息安全性。但是，與服務(wù)器不同，智能設(shè)備性能相對較低，引入虛擬化技術(shù)的同時也帶來了額外的性能開銷，而這種開銷是不可忽視的。如果在非虛擬化條件下，智能設(shè)備也可以運行多個操作系統(tǒng)實例且相互隔離，那么既提升了信息安全性，又不產(chǎn)生額外的性能開銷，可以達(dá)到兩全其美的效果。本文針對這一問題進(jìn)行了探索與研究，提出并實現(xiàn)了Mux OS（Multiplex Operating System）。

Mux OS是一種適用于智能設(shè)備的多重操作系統(tǒng)架構(gòu)，可以在非虛擬化環(huán)境下協(xié)調(diào)多個基于Linux內(nèi)核的操作系統(tǒng)獨立且隔離地運行在同一智能設(shè)備中，可實現(xiàn)操作系統(tǒng)間亞秒級的快速切換。

2 總體設(shè)計

2.1 系統(tǒng)架構(gòu)

如圖1所示，MuxOS將物理內(nèi)存劃分成若干不相交區(qū)域，每個區(qū)域加載著一個操作系統(tǒng)實例。通過控制策略，每個實例可以訪問自己及公共區(qū)域的物理內(nèi)存。每段時間內(nèi)只有一個實例處于運行狀態(tài)（前臺），其它實例處于暫停狀態(tài)（后臺）。處于運行狀態(tài)的實例可以使用CPU及外設(shè)，可以切換到其它實例。

Figure 1 Architecture of Mux OS圖1 Mux OS架構(gòu)

2.2 加載操作系統(tǒng)

在Mux OS架構(gòu)中，依據(jù)加載方式不同，操作系統(tǒng)分為兩類：FMKernel（First loaded Mux OS Kernel，第一個加載的操作系統(tǒng)）和OMKernels（Other Mux OS Kernel（s），其它操作系統(tǒng)）。FMKernel與OMKernels是加入Mux OS功能的基于Linux內(nèi)核的操作系統(tǒng)。

2.2.1 加載FMKernel

FMKernel的加載方式與一般操作系統(tǒng)的啟動方式相同，如圖2所示。FMKernel在啟動參數(shù)中加入了對整個物理內(nèi)存的劃分設(shè)置。例如，“OMKernels＝600M＠200M Public Area＝1M＃900M”表示：OMKernels的內(nèi)存范圍是［200M，200＋600M），公共區(qū)的內(nèi)存范圍是［900M，900＋1M），F(xiàn)MKernel的內(nèi)存范圍是剩余空間，內(nèi)存分布如圖3所示。

Figure 2 Loading process of FMKernel圖2 FMKernel加載流程

Figure 3 Memory structure of Mux OS圖3 MuxOS內(nèi)存分布

2.2.2 加載OMKernels

OMKernels的加載方式與FMKernel的不同，它（們）在正在運行著的FMKernel中被動態(tài)加載至內(nèi)存指定區(qū)域。實現(xiàn)方法上，Mux OS借鑒了kexec［5］/kdump［6］：FMKernel可以看作是kexec/kdump中的原內(nèi)核，OMKernels可以看作是捕獲內(nèi)核。Mux OS在kexec/kdump基礎(chǔ)上做了如下改動：

（1）改變了捕獲內(nèi)核的觸發(fā)機(jī)制：kexec/kdump在原內(nèi)核崩潰時自動觸發(fā)啟動捕獲內(nèi)核；Mux OS在用戶控制下加載OMKernels。

具體來說，kexec啟動新內(nèi)核分為兩個階段：加載和運行。新內(nèi)核分為兩種：普通內(nèi)核和捕獲內(nèi)核。在加載階段，對于普通內(nèi)核，kexec動態(tài)地查找當(dāng)前系統(tǒng)中的空閑內(nèi)存并分配使用；對于捕獲內(nèi)核，kexec直接使用啟動時保留的內(nèi)存區(qū)域。在運行階段，普通內(nèi)核的加載是由用戶控制的，捕獲內(nèi)核的加載是系統(tǒng)崩潰時自動調(diào)用的。Mux OS則綜合了捕獲內(nèi)核的加載方法以及普通內(nèi)核的觸發(fā)方法，實現(xiàn)了OMKernels的可控加載。

（2）擴(kuò)展了捕獲內(nèi)核的數(shù)量：kexec/kdump只能啟動一個捕獲內(nèi)核且該內(nèi)核占用全部系統(tǒng)啟動時設(shè)置的保留內(nèi)存；Mux OS可以啟動多個OMK－ernels且分別占用保留內(nèi)存的一部分。

具體來說，kexec/kdump通過“/proc/iomem”文件獲取當(dāng)前系統(tǒng)的內(nèi)存設(shè)置，如表1所示，“Crash kernel”標(biāo)記了保留內(nèi)存區(qū)域。當(dāng)系統(tǒng)崩潰時，kexec/kdump直接將這部分內(nèi)存分配給捕獲內(nèi)核使用。Mux OS使kexec/kdump不再訪問“/proc/iomem”文件，而是它的一個副本，通過反復(fù)修改副本中的“Crash kernel”的參數(shù)，依次加載全部OMKernels。

Table 1 Contents of iomem表1 iomem文件內(nèi)容

2.2.3 基于休眠鏡像的快速啟動

Mux OS采用了基于休眠鏡像的快速啟動技術(shù)。無論是FMKernel還是OMKernels，如果內(nèi)核在啟動階段檢測到磁盤中存在自身的休眠鏡像，則跳過操作系統(tǒng)初始化階段，直接將鏡像恢復(fù)至內(nèi)存，以減小時間開銷。通常情況下，Linux內(nèi)核在執(zhí)行休眠操作時，將休眠鏡像寫入Swap分區(qū)，并在分區(qū)頭部做一個休眠標(biāo)記。操作系統(tǒng)在啟動時一旦檢測到休眠標(biāo)記便不會進(jìn)入初始化流程，而是從Swap分區(qū)中讀取鏡像并恢復(fù)至內(nèi)存，同時將Swap分區(qū)頭部的休眠標(biāo)記清除，這樣在下一次啟動時不會重復(fù)進(jìn)行休眠恢復(fù)操作。Mux OS在此基礎(chǔ)上將原來的一個休眠標(biāo)記擴(kuò)展為兩個：LabelOnce、Label Always。如果內(nèi)核在啟動時發(fā)現(xiàn)Swap分區(qū)存在LabelOnce標(biāo)記，則在恢復(fù)操作后清除LabelOnce標(biāo)記，那么只進(jìn)行一次恢復(fù)操作；如果內(nèi)核在啟動時發(fā)現(xiàn)swap分區(qū)存在Label Always標(biāo)記，則在恢復(fù)操作后不清除Label Always標(biāo)記，那么設(shè)備每次啟動都會進(jìn)行恢復(fù)操作。

對于智能設(shè)備廠商來說，出于對設(shè)備的保護(hù)，不希望用戶對操作系統(tǒng)進(jìn)行任何改動。那么，可以將預(yù)先制作好的鏡像固化到存儲設(shè)備中，將休眠標(biāo)記設(shè)置為Label Always，于是每次開啟設(shè)備都會從鏡像中恢復(fù)，不僅確保了操作系統(tǒng)的完整性，而且可以縮短設(shè)備啟動時間，提升用戶體驗。

2.3 切換操作系統(tǒng)

快速切換操作系統(tǒng)是Mux OS的主要設(shè)計目標(biāo)之一。Mux OS通過保存與恢復(fù)操作系統(tǒng)上下文實現(xiàn)了多操作系統(tǒng)實例間的切換。操作系統(tǒng)上下文包括內(nèi)存狀態(tài)、外設(shè)狀態(tài)以及CPU寄存器狀態(tài)。

對于內(nèi)存狀態(tài)，由于Mux OS中操作系統(tǒng)各自使用不同的內(nèi)存區(qū)域，相互之間沒有交叉，所以在切換操作系統(tǒng)時，無需考慮內(nèi)存中內(nèi)容的保存與恢復(fù)問題，這是Mux OS能快速切換操作系統(tǒng)的主要原因，也是Mux OS架構(gòu)的優(yōu)勢所在。

對于外設(shè)狀態(tài)，Mux OS采用了待機(jī)（suspend to RAM）機(jī)制，即切換前將外設(shè)掛起，切換后再喚醒外設(shè)，保證了切換前后外設(shè)狀態(tài)的一致性。

對于CPU寄存器狀態(tài)，這是切換任務(wù)的難點與關(guān)鍵所在，要保證切換前后CPU寄存器內(nèi)容的一致性，即切換前操作系統(tǒng)運行到那里，切換回來后還要繼續(xù)從哪里運行。Mux OS將CPU寄存器分成兩類：一類是關(guān)鍵寄存器，指的是與內(nèi)核運行息息相關(guān)的寄存器，包括狀態(tài)控制寄存器，比如EFLAGS、EIP、CR0、CR3等，還包括一些通用寄存器，比如ESP、EBP、ESI、EDI等；另一類是非關(guān)鍵寄存器，比如EAX、EBX、ECX及EDX等。以從OS1切換至OS2為例：Mux OS首先將OS1非關(guān)鍵寄存器內(nèi)容保存到自身內(nèi)存區(qū)域中，然后將關(guān)鍵寄存器內(nèi)容保存至公共區(qū)域中，接著從公共區(qū)域讀取OS2關(guān)鍵寄存器內(nèi)容，而后恢復(fù)至相應(yīng)寄存器。實際上，此時已經(jīng)運行在OS2中，OS2恢復(fù)之前由自己保存的非關(guān)鍵寄存器內(nèi)容，然后繼續(xù)運行。

Mux OS公共區(qū)域存儲著Mux OS、FMKernel及OMKernels的相關(guān)信息。各操作系統(tǒng)實例對公共區(qū)域的訪問是需要解決的問題之一。因為Mux OS公共區(qū)域是用物理地址描述的，而各操作系統(tǒng)運行在保護(hù)模式下，CPU使用的是虛擬地址，這就需要物理地址向虛擬地址的轉(zhuǎn)換。這個轉(zhuǎn)換可以通過修改內(nèi)核頁表實現(xiàn)，但是比較繁瑣。Mux OS采用的是地址映射（Ioremap）的方法，首先在內(nèi)核空間中申請一塊空間，然后通過映射將這塊空間與目標(biāo)地址相關(guān)聯(lián)，程序則可以通過訪問這塊內(nèi)核空間來訪問目標(biāo)地址。

3 系統(tǒng)運行流程

（1）啟動階段。

智能設(shè)備啟動后，Mux OS將各操作系統(tǒng)加載至內(nèi)存并等待用戶使用，其流程如圖4所示。

（2）運行階段。

用戶正常使用智能設(shè)備并可在各操作系統(tǒng)實例間任意切換。

（3）關(guān)閉階段。

當(dāng)用戶需要關(guān)閉智能設(shè)備電源時，Mux OS依次將各操作系統(tǒng)內(nèi)存鏡像保存到磁盤中而后關(guān)機(jī)。

Figure 4 Loading process of operating systems圖4 操作系統(tǒng)加載流程

4 性能分析

4.1 MuxOS、Xen及原始主機(jī)的性能對比

本文對MuxOS、Xen及原始主機(jī)分別進(jìn)行了關(guān)于CPU、內(nèi)存以及IO性能的測試，選用的benchmark有C－Ray、RAMspeed以及IOzone。為了使測試結(jié)果具有可比性，測試在同一物理機(jī)上進(jìn)行。首先測試了原始主機(jī)的性能；然后在物理機(jī)上安裝Xen 4.1.2，添加內(nèi)存為1 GB的虛擬機(jī)Domain 1并測試了Domain 1的性能；最后在物理機(jī)上部署Mux OS，運行兩個操作系統(tǒng)，各占用1 GB內(nèi)存，測試了OMKernels的性能。測試結(jié)果如圖5～圖7所示。

Figure 5 C－Ray result圖5 C－Ray測試結(jié)果（s）

通過測

試結(jié)果可以看出：

（1）Mux OS與原始主機(jī)性能相當(dāng)。

這是因為Mux OS與原始主機(jī)相比，只是操作系統(tǒng)運行在內(nèi)存中的位置改變了，沒有產(chǎn)生額外的性能開銷，所以兩者性能相當(dāng)，Mux OS可以最大程度發(fā)揮設(shè)備性能。

Figure 6 RAMspeed result圖6 RAMspeed測試結(jié)果（MB/s）

Figure 7 IOzone result圖7 IOzone測試結(jié)果（MB/s）

（2）Mux OS優(yōu)于Xen性能。

這是因為Mux OS沒有使用虛擬化技術(shù)，操作系統(tǒng)直接與硬件設(shè)備打交道。而虛擬化環(huán)境下，無論是完全虛擬化還是半虛擬化，操作系統(tǒng)都不是直接與硬件設(shè)備打交道，需要hypervisor的介入，產(chǎn)生了額外的性能開銷。另外，在一段時間內(nèi)，Mux－OS只有一個操作系統(tǒng)實例處于運行狀態(tài)，其它實例處于暫停狀態(tài)，全部計算資源都由當(dāng)前操作系統(tǒng)占有。虛擬化環(huán)境下，所有操作系統(tǒng)都處于運行狀態(tài)，計算資源由多個操作系統(tǒng)分享。從實時性與用戶體驗的角度講，Mux OS更占優(yōu)勢。

4.2 切換操作系統(tǒng)的時間開銷

快速切換操作系統(tǒng)是Mux OS的主要設(shè)計目標(biāo)之一。本文在Mux OS架構(gòu)下，測試了五組每組10次操作系統(tǒng)切換時間，五組測試的平均值如圖8所示。可見，Mux OS切換操作系統(tǒng)平均時間為0.67 s，實現(xiàn)了亞秒級的快速切換。

Figure 8 Time overhead of switching operating system圖8 切換操作系統(tǒng)的時間開銷（s）

5 結(jié)束語

本文提出并實現(xiàn)了Mux OS，可以在非虛擬化環(huán)境下協(xié)調(diào)多個基于Linux內(nèi)核的操作系統(tǒng)運行于同一智能設(shè)備，可以實現(xiàn)上述操作系統(tǒng)之間亞秒級的快速切換，可以解決智能設(shè)備在非虛擬化條件下運行多操作系統(tǒng)問題，可以解決智能設(shè)備多情景下安全應(yīng)用問題。同時，其實現(xiàn)思路及方法在其它非虛擬化領(lǐng)域也可起到拋磚引玉的作用。

下一步我們將在兩個方面對Mux OS進(jìn)行探索和改進(jìn)。一是實現(xiàn)一個微內(nèi)核的FMKernel，作為整個Mux OS的管理系統(tǒng)，占用內(nèi)存很小，可以對整個物理內(nèi)存進(jìn)行休眠與恢復(fù)操作，減少Mux－OS的啟動時間，可以協(xié)調(diào)管理其它OMKernels的啟動與關(guān)閉。二是實現(xiàn)內(nèi)存的動態(tài)調(diào)整，使得OMKernels在運行時可以申請使用其它OMKernels的內(nèi)存空間，也可以在暫停時保存其內(nèi)存鏡像到磁盤中，進(jìn)而釋放內(nèi)存供其它OMKernels使用。

［1］ Barham P，Dragovic B，F(xiàn)raser K，et al.Xen and the art of virtualization［C］∥Proc of the 19th ACM Symposium on Operating Systems Principles，2003：164－177.

［2］ Andrus J，Dall C，Hof A V，et al.Cells：A virtual mobile smartphone architecture［C］∥Proc of the 23rd ACM Symposium on Operating Systems Principles，2011：173－187.

［3］ Barr K，Bungale P，Deasy S，et al.The VMware mobile virtualization platform：is that a hypervisor in your pocket？［J］.ACM SIGOPS Operating Systems Review，2010，44（4）：124－135.

［4］ Joshi A，Pimpale S，Rathi S，et al.Twin－Linux：Running independent linux kernels simultaneously on separate cores of a multicore system［C］∥Proc of Linux Symposium，2010：101－108.

［5］ Reducing system reboot time with kexec［EB/OL］.［2004－03－16］.http：∥lsd.googlecode.com/svn－h(huán)istory/r7/trunk/docs/kexec.pdf.

［6］ Goyal V，Biederman E W，Nellitheertha H，et al.Kdump：A kexec based kernel crash dumping mechanism［C］∥Proc of the Linux Symposium，2005：169－181.

［7］ Kozuch M A，Kaminsky M，Ryan M P.Migration without virtualization［C］∥Proc of the 12th Conference on Hot Topics in Operating Systems，2009.

［8］ Nomura Y，Senzaki R，Nakahara D，et al.Booting multiple linux kernels on a multicore processor［C］∥Proc of BWCCA’11，2011：555－560.