谷德賀,顧乃杰,劉博文,蘇俊杰,賀愛香
1(中國科學技術大學 計算機科學技術學院,合肥 230027)
2(中國科學技術大學 安徽省計算與通信軟件重點實驗室,合肥 230027)
3(中國科學技術大學 先進技術研究院,合肥 230027)
4(安徽新華學院 信息工程學院,合肥 230088)
基于LXC的Android系統虛擬化技術①
谷德賀1,2,3,顧乃杰1,2,3,劉博文1,2,3,蘇俊杰1,2,3,賀愛香1,4
1(中國科學技術大學 計算機科學技術學院,合肥 230027)
2(中國科學技術大學 安徽省計算與通信軟件重點實驗室,合肥 230027)
3(中國科學技術大學 先進技術研究院,合肥 230027)
4(安徽新華學院 信息工程學院,合肥 230088)
虛擬化技術的研究正逐漸從高性能服務器端轉向移動智能設備領域. 現有的虛擬化方案多是采用多內核方案,系統負載高,效率低. 針對車載系統等平臺多屏顯示以及資源受限等問題,本文提出一種基于容器技術的Android輕量級虛擬化方案. 該方案通過利用Namespace資源隔離機制和Cgroup資源分配機制,使得ARM平臺在資源使用較少的同時,能夠同時啟動多個Android虛擬機,并且各虛擬機上的屏幕顯示相互獨立. 測試結果表明,該方案的內存占用率較雙系統方案降低了7%,而平均CPU使用率較原生Android系統僅增加了1%.
虛擬化技術; 資源隔離; 資源分配; ARM 平臺; 虛擬機
近年來云計算[1]的快速發展,虛擬化技術[2]被廣泛應用于高性能服務器,以提高系統資源的利用率. 同時,隨著智能手機等移動終端的普及[3],智能終端扮演著越來越重要的角色,用戶對視頻、微信、新聞瀏覽等功能的使用開始從PC轉移至移動終端. 由于生活和工作等場景的多樣化,用戶不得不攜帶多個終端設備以滿足不同應用場景的需要,例如車載系統上司機和乘客同時對導航以及娛樂系統的需求. 與此同時,面對惡意廣告、病毒以及隱私信息泄露[4-6]等問題,更多的用戶開始關注移動平臺[7]的隱私安全性問題.
通過虛擬機機制[8],將多個獨立且隔離的智能手機軟件實例運行在同一個ARM硬件上,可以有效解決Android設備的安全風險. 現有的虛擬化方法都對用戶層和內核層做了大量地修改,如哥倫比亞大學提出的Cells模型[9]; 或利用ARM平臺的Hypervisor模式[10],如KVM/ARM架構[11]; 或設計完整的微內核模式,如OKL4的微內核模型[12],將宿主系統和客戶機系統隔離運行. 這些方案對于高性能服務器可能有效,但應用于智能手機主要有兩個問題. 其一,智能手機資源的受限,運行整個額外的操作系統以及用戶空間環境,將帶來很大的系統開銷,導致系統響應速度過慢; 其二,部分方法對內核層進行大量地修改,導致宿主系統和客戶機系統很難升級和擴展,對于頻繁的Android更新,這將帶來很大的工作量.
LXC[13]即 Linux Container,是利用 Linux 內核容器特性為用戶提供空間接口的開源工具,其通過強大的API和簡單的工具,可以讓用戶輕松創建和管理系統或者應用程序容器. LXC利用內核支持的資源隔離以及控制機制,通過對容器的配置,使用lxc-start等工具對容器進行控制,可以快速部署,且具有更小的虛擬化開銷等優點.
針對移動設備資源的受限,以及車載系統對于多屏顯示的需求,本文利用LXC開源工具提出一種Android系統輕量級虛擬化多屏顯示方案. 本方案是一種系統級虛擬化方案,通過利用Linux內核支持的虛擬化特性,在對內核盡可能少的修改前提下,將多個系統獨立的運行在同一個ARM平臺上且擁有不同的顯示屏幕. 本方案中多個系統共用同一個內核,其所帶來的系統負載小,即使在性能較差的平臺也不會影響用戶體驗,且具有容易部署和可擴展性強等優勢.
現有的移動虛擬化技術主要從以下幾個方面來隔離宿主系統,分別為操作系統級虛擬化方案、基于Hypervisor監管程序方案[14]和基于微內核方案[14].
操作系統級虛擬化將系統的命名空間劃分為不同的虛擬機. 虛擬機之間共享唯一的系統內核以及主機環境,每個虛擬機只保存本地環境的狀態,本文也是采用此解決方案. Cells[9]是哥倫比亞大學提出的基于操作系統級虛擬化的解決方案. Cells引入了一種前端虛擬手機(VP)和多個后臺虛擬手機的使用模型,使多個VP可以互不干擾、獨立運行; 且基于Namespace思路提出一種新的Device命名空間機制,使不同設備具有不同的訪問權限,例如不可訪問、共享訪問以及互斥訪問,使手機硬件得到很好的復用和隔離. 但Cells對Linux內核層做了大量的修改,使得其不可能并入Linux主線中. 不同的是,本文在未對內核層做大量地修改的情況下,同樣完成了系統需求.
KVM/ARM[11]是一個基于ARM平臺Hypervisor模型的完整系統虛擬化解決方案. KVM/ARM與其他虛擬化方案最大的區別在于大多數VMM都實現主要的服務,例如調度器、內存管理以及時鐘等. KVM利用現有 Linux Kernel的功能,以及硬件支持,使得虛擬技術的系統性能負載很小.
KVM/ARM引入一種技術,使其可以在CPU不同特權模式下運行. 通過該技術利用ARM硬件虛擬化支持進入監管模式,在統一時間內利用內核模式運行現有的Linux內核服務. 該方案中不同系統使用各自的內核,且上下文切換帶來的系統消耗較多,不適用資源受限的移動設備.
微內核[15]采用最小化原則,在保證能夠實現全部功能的前提下使內核盡量的小. OKL4[12]是從Open Kernel Labs出現的一種基于微內核的虛擬化技術.OKL4通過構建一種簡單的內核,提供比Hypervisor監管程序的更高效率,而且設計的微內核具有一定的通用性,可以在多平臺以及多系統上構建. 通過vCPUs、vMMU、vIRQs以及TLB相應的硬件支持,微內核足夠小,并可以正確的支持所有功能. 使得通過OKL4的系統負載足夠小. 但因為其需要設備支持以及仿真支持,對于目前日益多元化的移動設備來說,是一個繁重的硬件設備要求,也增加了硬件的成本.
針對車載系統等平臺多屏顯示以及資源受限等問題,本文提出一種輕量級虛擬化方案. 該方案主要包括系統的總體架構以及多屏顯示方案.
利用Linux內核中Namespace的資源隔離機制和Cgroup[16]的資源控制機制,以及輕量級容器工具LXC的特性,本文采用操作系統級虛擬化解決方案. 通過LXC工具對容器系統進行管理以及操作,利用內核機制的支持,LXC工具小且功能完善等優勢,完成多系統虛擬化的需求.
命名空間將LXC啟動的進程隔離放入獨立的命名空間中,通過Android init進程初始化Android系統,形成獨立的一組進程視圖. 同時Cgroup機制負責不同系統的資源的配置,分配CPU節點和Memory節點,以及監控容器空間內系統的運行狀況. 這樣在容器空間內的進程只能感受到當前容器的狀況.
Cgroups可以為不同用戶層面的資源管理,提供一個統一化的接口. 從單個進程的資源控制到操作系統層面,Cgroup 主要提供三個主要功能: 1) 資源限制:Cgroup可以對進程組使用的資源總額進行限制; 2) 優先級分配: 通過分配CPU時間片數量及硬盤IO帶寬大小,實際上就相當于控制進程的優先級; 3) 資源統計: Cgroup可以統計系統的資源使用量,如CPU使用時長、內存使用量等. 本文的架構如圖1所示.

圖1 系統架構圖
基于宿主機以及Android系統的特性,底層硬件共享同一個CPU、Memory、GPU等設備,但不同系統擁有不同的顯示設備以及輸入輸出設備,多個系統間共享同一個Linux內核,需要針對不同的顯示以及輸入輸出設備作設備,設計隔離以及復用方案,而GPU與CPU不同,其本身具有隔離性,不同應用程序均持有獨立的顯示上下文信息,不需要進行單獨的處理. 在宿主機中配置LXC工具,通過LXC工具就可以同時啟動不同的系統.
本方案采用LXC作為容器虛擬化工具,通過利用內核中命名空間的隔離機制和進程資源控制組對資源進行劃分,使得宿主系統與不同客戶機系統能夠隔離,相互不影響,并且流暢地運行. 該方案使得單個硬件設備即可運行多個虛擬系統,每個系統運行標準的Andoird環境,每個Android系統運行著未修改的Android應用程序. 每個虛擬系統完全隔離,不能檢查,篡改或者訪問任何其他的虛擬機.
每個虛擬系統可以被創建和配置通過PC機下載到開發板. 虛擬機系統可以被用戶刪除,但是其配置權限是通過密碼保護的,只能擁有權限的用戶才能在PC 機上改變. 例如,對于管理員可以創建虛擬機,下載或使其從設備上移除,但普通用戶不能重新配置,這對于虛擬機系統來說有很好的安全保障.
由于本文中所使用的硬件平臺是共享單個CPU、GPU以及內存設備,但擁有兩塊不同的顯示屏幕,因此對多個系統同時顯示在不同屏幕上單獨設計方案.
Android采用分層的架構設計,將系統分為四層:應用層,應用程序框架層,運行庫存,Linux 內核層.Android對Linux內核驅動程序進行封裝,提出硬件抽象層,Android的顯示系統硬件抽象層提供的是Gralloc,分別負責對framebuffer以及幀緩沖區的分配和釋放.Linux內核驅動層提供了FrameBuffer顯示驅動程序,其設備驅動程序的設備文件通常放在/dev/graphics/fb0或者是/dev/fb0.
利用不同顯示設備在系統中存在不同的設備節點,以及宿主Linux和客戶機Android系統的特性,提出雙屏顯示方案. 其架構如圖2. 對于宿主Linux系統使用QT交互界面默認使用/dev/fb0對應的屏幕設備,Android客戶機系統通過LXC容器啟動,將Android的顯示畫面輸出到fb1對應的屏幕中,從而實現雙屏同時顯示Qt Linux系統與Android系統畫面.
在Linux中,FB的使用模式是通過兩種的訪問類型: mmap和標準的ioctl操作. 不同虛擬機對底層不同的FrameBuffer驅動進行映射,同時底層FrameBuffer的驅動在內存分配上也是相互隔離的. 這樣就使得不同系統的訪問流相互隔離,從而達到顯示隔離的效果.最后GPU將渲染的數據直接寫入對應的buffer中,與CPU處理的內存并不同,GPU是直接對FrameBuffer進行操作,與CPU處理的數據是相互獨立的. 相較于在Android的服務層做修改,本方案不會改變Android的通用接口,使得實現方案更加具有通用性. 同時本方案將Android系統應用程序的數據直接顯示在fb1上,使得多系統顯示數據得到很好的隔離. 并且不同系統均可以正常顯示,相互之間沒有影響.

圖2 雙屏顯示方案
為了實現當前的設計方案,需要完成以下工作:
(1) 對 Linux kernel進行定制,開啟 Namespace 機制和Cgroup機制在內核中的選項. 使用指定的交叉編譯工具,移植LXC工具到宿主系統中.
(2) 制作Android容器文件系統,使得LXC可以啟動客戶機系統.
(3) 完成Android系統對顯示的需要,對不同系統顯示進行隔離.
使用LXC的工具的前提是Linux內核支持Namespace機制和Cgroup機制,雖然現在Namespace和Cgroup加入到內核中,但是其默認功能是沒有開啟的.需要手動打開Kernel對應的選項,并重新編譯內核,目前使用的Kernel版本是3.4.35.
由于使用定制的ARM平臺交叉工具,所以編譯過程會和普通GCC編譯不同,需要的依賴項也不同. 為了提高通用性,在腳本中加入對各個平臺依賴的判斷.這里使用的編譯工具是armv6-gcc,為了使LXC工具正常編譯,系統需要安裝automake等工具,提前編譯libcap庫. 但為了并對LXC源碼進行了修改,其主要修改的內容有:
(1) 與 Android 系統不兼容部分,例如 setenv,share,tmpfile 等函數,在 Linux 平臺與 Android 平臺中,其基礎函數庫參數以及實現方式不同,從而影響LXC正常執行.
(2) 無法正常編譯的問題,例如部分宏出現未定義問題,需要增加相應的頭文件.
(3) 相關邏輯的修改,使得可以啟動Android容器,且不需要修改通用的API接口.
執行make以及make install,將交叉編譯好的LXC工具移植到ARM平臺的機器中,通過使用LXC工具集中的lxc-checkconfig來檢測kernel選項是否打開以及其他功能是否運行正常. 并且可以通過嘗試創建一些模板容器,檢查LXC是否可以正常運行.
根據LXC容器創建過程以及Android系統啟動分析,由于存儲容量有限,且原生的Anroid文件系統需相應的修改,才可以在Linux Container中正常的運行.
宿主機系統采用普通的嵌入式Linux系統,則為了啟動Android客戶機系統,使用LXC啟動命令(lxcstart)將客戶機系統順利啟動,需要在Linux系統中創建容器系統. 在LXC工具指定的路徑建立容器的名稱,不同的客戶機的文件目錄是相互隔離的. 同時也可以通過設置共享相應的客戶機的庫文件等. 不同的目錄對應不同的客戶機系統,這樣運行時不同的客戶機系統之間無法感知其他系統的文件系統.
主要的文件目錄如圖3,對于宿主機系統都有其容器名,其中rootfs為其Android客戶機系統的目錄文件. 其目錄下包含Android系統啟動必須的文件,修改原Android系統的init.rc文件,關閉不必要的服務,修改其創建的設備節點用來與宿主系統隔離和復用,修改掛載的文件系統,復用宿主系統的文件,提升低端設備的擴展性,以及隔離需要隔離的文件目錄. 通過自動化腳本配置容器信息,提升容器配置的通用性.
由于本文中ARM平臺的硬件設備是一個CPU,Memory但是擁有兩個屏幕硬件設備,在Linux中每個應用程序通過mmap系統調用,將顯存映射到應用程序對應進程的虛擬地址空間中,可以直接將所需要顯示的內容直接寫入內存空間,通過實現一系列文件操作接口,使得應用程序可以直接操作字符設備,最終LCD控制器自動將顯存中的內容顯示在屏幕設備中.

圖3 Android 容器目錄文件結構
Android系統在設計之初只考慮單屏的存在,因此對于移動設備來說,因為只存在一個屏幕,在字符設備節點中默認只有/dev/fb0或者/dev/graphics/fb0存在. 對于 Android 應用程序,通過 SurfaceFlinger服務,調用libgl庫進行圖像處理,將顯示數據交給硬件邏輯層Gralloc,最終底層FrameBuffer驅動以及GPU驅動將需要顯示的內容刷新在顯示設備中. Gralloc對于復雜的顯示驅動,保證Android上層應用顯示接口不變. 因此選擇對Android硬件抽象層Gralloc中作出相應的修改,實現Android客戶機系統可以正常顯示在第二塊屏幕上.
通過對Android系統的源碼分析,用戶空間使用FrameBuffer設備,首先通過load加載Gralloc模塊.從Gralloc層打開fb設備的流程可知,在保證Android顯示正常,只需要對Gralloc模塊加載的fb設備作出相應的修改就可以實現雙屏顯示的方案,因此在該硬件抽象層加入相應的邏輯修改,其主要工作為:
(1) 將Gralloc模塊關于打開fb0設備的邏輯做相應的修改,使得加載Gralloc模塊時將不是默認打開fb0設備,使得Android設備可以在fb1對應的顯示屏能夠正常顯示.
(2) 拒絕容器打開的客戶機系統對Linux中對應fb0的字符設備節點打開的權限,使得從客戶機系統角度來看也只有一個顯示設備節點存在.
(3) 在LXC啟動容器的流程中,加入對fb1設備加載的邏輯. 考慮到fb1設備一直打開,損失移動設備的電量,在lxc-start的啟動流程中加入對fb1設備加載的相應邏輯,達到節約能耗的目的.
實驗測試環境是在ARM平臺車載系統開發板上,使用 Linux kernel 3.4.35 版本,Android 對應 4.2.2 版本,基于LXC1.0.7的虛擬化解決方案,其硬件實驗環境為:雙核 ARM Cortex A7、1GB DRAM、8GB eMMC. 因其平臺硬件資源有限,只啟動雙系統進行測試.
通過燒制系統集成Image,打開電源開關,宿主Linux系統和客戶機Android系統同時啟動,宿主系統顯示其開機Logo,Android系統在另一個顯示器顯示“ANDROID”字樣,代表兩個系統通過宿主系統的命令啟動成功; Android系統通過LXC工具正常啟動,且通過兩個屏幕分別顯示不同系統界面,互相隔離相互不影響,表明雙屏顯示方案正常; 且通過45項系統以及硬件功能的Sanity Test測試.
同時通過多次的開關機重啟,雙系統同時畫面幾乎同時啟動且正常顯示,表示其功能正常且穩定. 且鼠標,鍵盤輸出輸出設備不會在Android系統中響應,只能點擊和響應QT的界面,同時對于Android系統使用自帶的觸摸屏去觸摸點擊,可以正常交互和顯示.
通過讀取/proc/meminfo信息統計不同系統情況下,內存的使用的情況,在開機30分鐘穩定后得到的數據情況如圖4.

圖4 內存使用情況
我們根據2016年Google熱門app榜單,選取社交類、影音類、游戲類三類,分別測試微信、音樂播放器、部落沖突,代表不同的應用場景,將虛擬化后的CPU使用率與原生Android的CPU使用率進行對比,得到10秒的時間內的增長率,詳情如表1所示.
從表中可以看出,不同種類的應用的CPU使用率的增長情況不同,但總體情況類似. 相比較來說可以看出原生的Android系統在啟動APP時的速度較快一些,不過兩者的CPU使用率相差不大,在實際使用的場景下基本感受不到兩者的差距. 根據三種應用的使用率情況看,其虛擬化后的Android系統的平均CPU使用率僅比原生系統高1%,性能與原生系統較相近.

表1 三類 app 的 CPU 利用率變化
針對車載系統等平臺多屏顯示的需求,本文提出一種基于容器技術Android輕量級虛擬化方案. 相較于傳統多核虛擬化方案,本方案只需要單個內核即可支持多個Android容器,具有更低的資源開銷和更高的性能. 從而實現用戶對不同場景以及隱私信息安全的需求. 測試結果表明: 在ARM 平臺上,該方案的內存占用率較雙系統方案降低了7%,而平均CPU使用率較原生Android系統僅增加了1%. 但是本文所提出的雙屏顯示方案還不夠完善,對不同輸入輸出設備的隔離和復用采取不同的策略,下一步的將圍繞隔離以及復用框架的通用性展開進一步工作.
1Armbrust M,Fox A,Griffith R,et al. A view of cloud computing. Communications of the ACM,2010,53(4): 50–58. [doi:10.1145/1721654]
2陳全,鄧倩妮. 云計算及其關鍵技術. 計算機應用,2009,29(9): 2562–2567.
3TrendForce: 2015年全球智能手機出貨12.93億部,華為躍升全球第三并突破一億部. http://press.trendforce.cn/press/20160114-2266.html. [2016-01-14].
4Enck W,Ongtang M,McDaniel P. Understanding android security. IEEE Security & Privacy,2009,7(1): 50–57.
5楊健,汪海航,王劍,等. 云計算安全問題研究綜述. 小型微型計算機系統,2012,33(3): 472–479.
6蔣紹林,王金雙,張濤,等. Android 安全研究綜述. 計算機應用與軟件,2012,29(10): 205–210.
7Android Platform. https://developer.android.com/about/android.html.
8Aguiar A,Hessel F. Current techniques and future trends in embedded system’s virtualization. Software: Practice and Experience,2012,42(7): 917–944. [doi: 10.1002/spe.v42.7]
9Andrus J,Dall C,van’t Hof A,et al. Cells: A virtual mobile smartphone architecture. Proc. of the Twenty-Third ACM Symposium on Operating Systems Principles. Cascais,Portugal. 2011. 173–187.
10Uhlig R,Neiger G,Rodgers D,et al. Intel virtualization technology. Computer,2005,38(5): 48–56. [doi: 10.1109/MC.2005.163]
11Varanasi P. Implementing Hardware-supported virtualization in OKL4 on ARM[Ph. D. thesis]. New South Wales: University of New South Wales,2010.
12Kivity A,Kamay Y,Laor D,et al. kvm: the Linux virtual machine monitor. Proc. of the Linux Symposium. 2007.225–230.
13LXC-Linux Containers. https://linuxcontainers.org/,2014.
14Chen XY. Smartphone virtualization: Status and challenges.2011 International Conference on Electronics,Communications and Control (ICECC). Ningbo,China. 2011. 2834–2839.
15毛德操,胡希明. Linux 內核源代碼情景分析 (上冊). 杭州:浙江大學出版社,2001.
16Rosen R. Linux containers and the future cloud. Linux Journal,2014,2014(240): 3.
Virtualization Technology of Android System Based on LXC
GU De-He1,2,3,GU Nai-Jie1,2,3,LIU Bo-Wen1,2,3,SU Jun-Jie1,2,3,HE Ai-Xiang1,4
1(School of Computer Science and Technology,University of Science and Technology of China,Hefei 230027,China)
2(Anhui Province Key Laboratory of Computing and Communication Software,University of Science and Technology of China,Hefei 230027,China)
3(Institute of Advanced Technology,University of Science and Technology of China,Hefei 230027,China)
4(Institute of Information Engineering,Anhui XinHua University,Hefei 230088,China)
The virtualization technology research is gradually moving from high-performance server to mobile intelligent devices. Existing virtualization solutions are mostly multi-core solution with high system overhead and low efficiency.This paper presents a lightweight virtualization scheme based on Linux container for multi-screen display and resource limitation of vehicle system. Our program,through the use of Namespace resource isolation mechanism and Cgroup resource control mechanism,can start several Android virtual machines on the ARM platform at the same time,while displaying on different screens and running independently. The performance test results show that on the ARM platform,the program uses less than 7% of the memory of the two systems,and the average CPU usage after virtualization is only 1% higher than the native Android system.
virtualization technology; resource isolation; resource control; ARM platform; virtual machine
谷德賀,顧乃杰,劉博文,蘇俊杰,賀愛香.基于 LXC 的 Android 系統虛擬化技術.計算機系統應用,2017,26(12):58–63. http://www.c-sa.org.cn/1003-3254/6110.html
安徽省自然科學基金(1408085MKL06); 高等學校學科創新引智計劃項目(B07033)
2017-03-15; 修改時間: 2017-03-31; 采用時間: 2017-04-07