一种适用于智能设备的多重操作系统架构＊

韩 威，陈 渝，刘迎莉，张久锋

（1.清华大学计算机系，北京100088；2.总参第61研究所，北京100039；3.65049部队，辽宁大连116100）

1 引言

近几年，智能手机、平板电脑等移动智能设备越来越普及，其信息安全问题逐渐显现并引起了人们的高度重视。虚拟化技术［1］是一种提高信息安全性的有效手段，针对移动智能设备的虚拟化研究成为当前操作系统领域的一个热点［2～4］。这些研究主要围绕如何提高信息安全性与降低虚拟化开销两条主线展开。通过虚拟化技术，移动智能设备可以像服务器一样运行多个操作系统实例，实例间相互隔离，提高了信息安全性。但是，与服务器不同，智能设备性能相对较低，引入虚拟化技术的同时也带来了额外的性能开销，而这种开销是不可忽视的。如果在非虚拟化条件下，智能设备也可以运行多个操作系统实例且相互隔离，那么既提升了信息安全性，又不产生额外的性能开销，可以达到两全其美的效果。本文针对这一问题进行了探索与研究，提出并实现了Mux OS（Multiplex Operating System）。

Mux OS是一种适用于智能设备的多重操作系统架构，可以在非虚拟化环境下协调多个基于Linux内核的操作系统独立且隔离地运行在同一智能设备中，可实现操作系统间亚秒级的快速切换。

2 总体设计

2.1 系统架构

如图1所示，MuxOS将物理内存划分成若干不相交区域，每个区域加载着一个操作系统实例。通过控制策略，每个实例可以访问自己及公共区域的物理内存。每段时间内只有一个实例处于运行状态（前台），其它实例处于暂停状态（后台）。处于运行状态的实例可以使用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），公共区的内存范围是［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中被动态加载至内存指定区域。实现方法上，Mux OS借鉴了kexec［5］/kdump［6］：FMKernel可以看作是kexec/kdump中的原内核，OMKernels可以看作是捕获内核。Mux OS在kexec/kdump基础上做了如下改动：

（1）改变了捕获内核的触发机制：kexec/kdump在原内核崩溃时自动触发启动捕获内核；Mux OS在用户控制下加载OMKernels。

具体来说，kexec启动新内核分为两个阶段：加载和运行。新内核分为两种：普通内核和捕获内核。在加载阶段，对于普通内核，kexec动态地查找当前系统中的空闲内存并分配使用；对于捕获内核，kexec直接使用启动时保留的内存区域。在运行阶段，普通内核的加载是由用户控制的，捕获内核的加载是系统崩溃时自动调用的。Mux OS则综合了捕获内核的加载方法以及普通内核的触发方法，实现了OMKernels的可控加载。

（2）扩展了捕获内核的数量：kexec/kdump只能启动一个捕获内核且该内核占用全部系统启动时设置的保留内存；Mux OS可以启动多个OMK－ernels且分别占用保留内存的一部分。

具体来说，kexec/kdump通过“/proc/iomem”文件获取当前系统的内存设置，如表1所示，“Crash kernel”标记了保留内存区域。当系统崩溃时，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内核在执行休眠操作时，将休眠镜像写入Swap分区，并在分区头部做一个休眠标记。操作系统在启动时一旦检测到休眠标记便不会进入初始化流程，而是从Swap分区中读取镜像并恢复至内存，同时将Swap分区头部的休眠标记清除，这样在下一次启动时不会重复进行休眠恢复操作。Mux OS在此基础上将原来的一个休眠标记扩展为两个：LabelOnce、Label Always。如果内核在启动时发现Swap分区存在LabelOnce标记，则在恢复操作后清除LabelOnce标记，那么只进行一次恢复操作；如果内核在启动时发现swap分区存在Label Always标记，则在恢复操作后不清除Label Always标记，那么设备每次启动都会进行恢复操作。

对于智能设备厂商来说，出于对设备的保护，不希望用户对操作系统进行任何改动。那么，可以将预先制作好的镜像固化到存储设备中，将休眠标记设置为Label Always，于是每次开启设备都会从镜像中恢复，不仅确保了操作系统的完整性，而且可以缩短设备启动时间，提升用户体验。

2.3 切换操作系统

快速切换操作系统是Mux OS的主要设计目标之一。Mux OS通过保存与恢复操作系统上下文实现了多操作系统实例间的切换。操作系统上下文包括内存状态、外设状态以及CPU寄存器状态。

对于内存状态，由于Mux OS中操作系统各自使用不同的内存区域，相互之间没有交叉，所以在切换操作系统时，无需考虑内存中内容的保存与恢复问题，这是Mux OS能快速切换操作系统的主要原因，也是Mux OS架构的优势所在。

对于外设状态，Mux OS采用了待机（suspend to RAM）机制，即切换前将外设挂起，切换后再唤醒外设，保证了切换前后外设状态的一致性。

对于CPU寄存器状态，这是切换任务的难点与关键所在，要保证切换前后CPU寄存器内容的一致性，即切换前操作系统运行到那里，切换回来后还要继续从哪里运行。Mux OS将CPU寄存器分成两类：一类是关键寄存器，指的是与内核运行息息相关的寄存器，包括状态控制寄存器，比如EFLAGS、EIP、CR0、CR3等，还包括一些通用寄存器，比如ESP、EBP、ESI、EDI等；另一类是非关键寄存器，比如EAX、EBX、ECX及EDX等。以从OS1切换至OS2为例：Mux OS首先将OS1非关键寄存器内容保存到自身内存区域中，然后将关键寄存器内容保存至公共区域中，接着从公共区域读取OS2关键寄存器内容，而后恢复至相应寄存器。实际上，此时已经运行在OS2中，OS2恢复之前由自己保存的非关键寄存器内容，然后继续运行。

Mux OS公共区域存储着Mux OS、FMKernel及OMKernels的相关信息。各操作系统实例对公共区域的访问是需要解决的问题之一。因为Mux OS公共区域是用物理地址描述的，而各操作系统运行在保护模式下，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可以最大程度发挥设备性能。

Figure 6 RAMspeed result图6 RAMspeed测试结果（MB/s）

Figure 7 IOzone result图7 IOzone测试结果（MB/s）

（2）Mux OS优于Xen性能。

这是因为Mux OS没有使用虚拟化技术，操作系统直接与硬件设备打交道。而虚拟化环境下，无论是完全虚拟化还是半虚拟化，操作系统都不是直接与硬件设备打交道，需要hypervisor的介入，产生了额外的性能开销。另外，在一段时间内，Mux－OS只有一个操作系统实例处于运行状态，其它实例处于暂停状态，全部计算资源都由当前操作系统占有。虚拟化环境下，所有操作系统都处于运行状态，计算资源由多个操作系统分享。从实时性与用户体验的角度讲，Mux OS更占优势。

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，可以在非虚拟化环境下协调多个基于Linux内核的操作系统运行于同一智能设备，可以实现上述操作系统之间亚秒级的快速切换，可以解决智能设备在非虚拟化条件下运行多操作系统问题，可以解决智能设备多情景下安全应用问题。同时，其实现思路及方法在其它非虚拟化领域也可起到抛砖引玉的作用。

下一步我们将在两个方面对Mux OS进行探索和改进。一是实现一个微内核的FMKernel，作为整个Mux OS的管理系统，占用内存很小，可以对整个物理内存进行休眠与恢复操作，减少Mux－OS的启动时间，可以协调管理其它OMKernels的启动与关闭。二是实现内存的动态调整，使得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－history/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.