一種適用于智能設備的多重操作系統架構＊

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

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

1 引言

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

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

2 總體設計

2.1 系統架構

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

Figure 1 Architecture of Mux OS圖1 Mux OS架構

2.2 加載操作系統

在Mux OS架構中，依據加載方式不同，操作系統分為兩類：FMKernel（First loaded Mux OS Kernel，第一個加載的操作系統）和OMKernels（Other Mux OS Kernel（s），其它操作系統）。FMKernel與OMKernels是加入Mux OS功能的基于Linux內核的操作系統。

2.2.1 加載FMKernel

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

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

Figure 3 Memory structure of Mux OS圖3 MuxOS內存分布

2.2.2 加載OMKernels

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

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

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

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

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

Table 1 Contents of iomem表1 iomem文件內容

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

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

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

2.3 切換操作系統

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

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

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

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

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

3 系統運行流程

（1）啟動階段。

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

（2）運行階段。

用戶正常使用智能設備并可在各操作系統實例間任意切換。

（3）關閉階段。

當用戶需要關閉智能設備電源時，Mux OS依次將各操作系統內存鏡像保存到磁盤中而后關機。

Figure 4 Loading process of operating systems圖4 操作系統加載流程

4 性能分析

4.1 MuxOS、Xen及原始主機的性能對比

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

Figure 5 C－Ray result圖5 C－Ray測試結果（s）

通過測

試結果可以看出：

（1）Mux OS與原始主機性能相當。

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

Figure 6 RAMspeed result圖6 RAMspeed測試結果（MB/s）

Figure 7 IOzone result圖7 IOzone測試結果（MB/s）

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

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

4.2 切換操作系統的時間開銷

快速切換操作系統是Mux OS的主要設計目標之一。本文在Mux OS架構下，測試了五組每組10次操作系統切換時間，五組測試的平均值如圖8所示。可見，Mux OS切換操作系統平均時間為0.67 s，實現了亞秒級的快速切換。

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

5 結束語

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

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

［1］ Barham P，Dragovic B，Fraser 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.