嵌入式高安全和高可靠性的虚拟化技术

1. 虚拟化技术概述

早在20世纪60年代，虚拟化技术就已经应用于大型机系统。然而直到20世纪90年代中期，桌面处理器技术的提升才真正开启了虚拟机技术在PC上的应用，嵌入式市场也由此开始利用这一个非常有前景的技术。从虚拟机使用资源角度考虑，虚拟机可以划分成两类：类型I与类型II。类型I的虚拟机直接运行在裸的硬件上，故称之为裸机虚拟机或者本地虚拟机；类型II的虚拟机运行在一个操作系统上面，比如VMware，Virtual box等等。运行在裸机上的操作系统称为主机操作系统(Host OS)，运行在虚拟机上的操作系统，称为客户操作系统(Guest OS)[1]。

虚拟化领域是一个非常活跃的领域，多种计算技术正在被研究和设计，比如全虚拟化技术、半虚拟化技术、以及二进制指令翻译技术，但是目前尚未有一个清晰的解决方案或者一种实现技术占统治地位[2]。本文主要研究的是在嵌入式实时系统上的虚拟化技术，考虑到嵌入式实时系统的实时性和可靠性，本文采用类型1的虚拟机，即使用裸机虚拟机Hypervisor，讨论裸机虚拟化技术、以及由此带来的可靠和安全性优势。

裸机虚拟机一般采用半虚拟化技术，所谓半虚拟化技术是指Hypervisor采用显式服务或者系统调用来替换冲突指令(冲突指令指的是那些直接操作硬件造成可能破坏虚拟平台VM(Virtual Machine)间相互隔离的指令)[3]。半虚拟化技术需要Guest OS显式地使用Hypervisor提供的半虚拟化接口，没有感知到半虚拟化技术的Guest OS是不能在Hypervisor上运行的。由于Guest OS需要定制(也称半虚拟化)，所以Guest OS的源码必须是可以获得的，半虚拟化技术不需要特定处理器硬件的支持，因而可以降低产品的开发成本。

2. 高可靠性Hypervisor设计

裸机虚拟化方案更快、更简单、也更小。裸机虚拟化方案采用半虚拟化技术，各个VM必须要认识到虚拟环境的局限性，使用Hypervisor提供的系统调用。裸机虚拟机设计核心是实现VM之间时间和空间上的隔离、基本资源(时钟和定时器、中断、内存、CPU时间，串行I/O等)的虚拟化、保证实时调度策略和系统调用的确定性、实现VM间的高效通信和快速上下文切换、以及较低的开销[4]。下面我们来分别讨论这些相关技术。

2.1 实现VM之间空间和时间上的隔离

在时间隔离方面，裸机虚拟化技术一般按照静态配置的调度策略严格执行，比如基于时间片的循环调度策略；为了在苛刻的实时环境中确保Hypervisor的可预测、提高调度策略的鲁棒性、降低时间上的开销，裸机虚拟机不采用动态调度策略，而采用静态配置的调度策略。这种调度策略的副作用是降低了非实时操作系统GPOS的吞吐量，由于GPOS需要更为灵活的调度策略，后面提到的设备虚拟化技术[5]充分考虑到了这一因素，最大程度上提高了GPOS的吞吐量。为了实现不同VM间的空间隔离，裸机虚拟机为每一个VM定义了一组物理内存区域，每个VM只能访问各自的内存空间，从而实现了虚拟之间的隔离。

2.2 Hypervisor和VM的特权级分配

一般来说CPU至少支持两种模式：用户级和特权级，并且在任意时刻CPU只能处于一种模式之下运行。如果特权模式被激活，特权程序可以执行所有的指令、访问所有的寄存器；反之，如果用户模式被激活，用户程序不能访问CPU中具有特权特征的指令集，只能执行CPU中所有指令和所有寄存器的子集。用户程序试图执行特权指令会被拒绝并触发一个异常。具有上述功能的CPU就可以部署支持半虚拟化的Hypervisor。

Hypervisor运行在特权模式，完全控制所有硬件资源，因而可以操作硬件平台在所有VM间共享。由于所有VM运行在用户模式下，但是VM中的虚拟处理器vCPU期望访问所有的硬件资源，因此Hypervisor必须提供一种间接的机制来实现vCPU期望得到的所有功能。由于用户模式下执行特权指令会产生一条陷阱，这种特征被Hypervisor用于捕获VM试图执行特权指令，然后模拟该特权指令的原有功能。Hypervisor捕获并模拟特权指令的流程如图所示。

如果异常产生的原因是CPU处于用户模式，但是vCPU处于特权模式时，该特权指令将会被Hypervisor模拟。由于CPU的寄存器值被映射到vCPU中，通过跟踪vCPU的机器状态字就可以知道vCPU的当前工作模式。如果异常产生的原因不是由于用户程序执行特权指令，或者此时vCPU正处于用户模式，那么该陷阱将直接传递到VM中。此时虽然CPU处于用户模式，但是如果vCPU处于特权模式，那么vCPU将会看到一个运行在特权态(虚拟特权态)的幻象。由于每一个特权指令在Hypervisor中都会有一个模拟历程，它将会被捕获陷阱的Hypervisor的异常例程所调用——这就是完全虚拟化技术的实质。

而半虚拟化技术需要VM通过执行一组设计好的系统调用和Hypervisor相协作，因而需要操作系统的源码针对Hypervisor的系统调用做出修改。这种系统调用类似于图1的调用过程。当一个系统调用由异常产生时，Hypervisor上下文中的相应中断ISR被调用，接着vCPU的状态被保存，如果vCPU处于特权模式，那么系统调用的请求将会被执行，否则vCPU处于用户模式，异常将会被返回到该vCPU，接着不论在任何情况下Hypervisor都会恢复vCPU的状态，并重新运行VM。

2.3 中断虚拟化

中断是提供给CPU用于处理异步事件的机制。当一个中断发生时，CPU将会转入特权模式并无条件的执行事先安排好的处理程序。例如Intel x86支持256种向量中断[6]，为使得处理器比较容易识别每一种中断，将它们从0~255编号，即赋予一个中断类型码n，Intel将这个8位的无符号整数称为一个向量，因此也叫中断向量，每一个中断向量都会对应一段处理程序。所有的256种中断可以分成三类：

硬件中断类：用于外部设备通过中断控制器向CPU发出中断请求，而引发的中断；

软件中断类：由处理器执行指令触发，比如Linux内核中系统调用指令int 0x80；

处理器异常类：由处理器触发的，报告阻止一条指令执行的条件，比如除0故障；

Hypervisor为每一个VM创建了一个虚拟执行环境，每个VM都不能直接操作硬件中断，即所有的硬件中断只能被Hypervisor捕获，并派发给相应的VM。当一个VM正在运行时，任何一种中断都可能发生。中断的目标可以是Hypervisor或者虚VM本身。但是所有的中断首先要被Hypervisor处理，然后被派发到适当的VM，其执行流程如图2所示。

图2中所中断也可以分成三类：

1)       当一个VM正在执行当中，硬件产生了中断，这时Hypervisor感知到了中断，将中断派发给VM；

2)       和CPU状态相关的中断(比如陷阱或者故障)在VM中发生，该中断由VM上的Guest OS传递到Hypervisor，由Hypervisor再次传递给正在运行的VM；

3)       虚拟中断直接传递给那些包含虚拟设备的VM。

在某些的情况下，Hypervisor不区分与实时活动相关的中断和非实时活动相关的中断。因此Hypervisor截获并处理所有的硬件中断，而仅仅把虚拟中断发送到相应的VM。为了防止VM间的时间隔离被打破，Hypervisor仅仅将中断发送给正在运行的VM处理，对于其他不在运行的VM，Hypervisor设置各个vCPU的中断Pending寄存器的相应比特位，以使得当该VM恢复运行时可以处理这个处于等待状态中的中断。

2.4 定时器虚拟化

Hypervisor的定时器是中断虚拟化的特例。这是由于定时器是系统的心脏，它使得硬件资源在各个VM间复用、或者在VM被各个应用复用，因而处于非常重要的地位。在Hypervisor设计中定时器实现了各个VM间的时间隔离。在hypervisor上存在两级定时器，Hypervisor级和VM级。Hypervisor执行了一个虚拟的定时器提供给VM调度服务例程使用，也提供给VM内部的部分例程使用。这样的话所有VM的内部定时精度(比如时钟tick)在处理之前必须是确定的，如果在下一个调度点到来之前，正在执行的VM的PIT耗尽的话，处理器的PIT值将根据VM来配置，否则它被配置成当前虚拟机的剩余时间片，直到下一个调度点，下图3所示。

2.5  设备虚拟化

当在Hypervisor上添加系统的I/O设备，通常有两种方案：

第一种方案：将对设备的管理集成到Hypervisor虚拟机中作为Hypervisor的一个子系统，这样的后果是使得Hypervisor的代码量和复杂度急剧上身，从而很难保证Hypervisor的安全和高效性，故通常只将很少的驱动集成到Hypervisor虚拟机中，比如控制台、串口驱动。

第二种方案：将设备驱动放置到VM中去实现，这种方法具有极大的灵活性，因为这可以利用现有的已经包含在Linux内核中的驱动程序。如果设备本身就是一个独占设备，那么它至多被分配给一个VM，不会有什么问题。但是如果设备需要在不同的VM间共享，这必须需要额外的管理方法。在操作系统的设备驱动中对于这类情形只要对该设备用互斥锁就可以保证I/O操作的原子性，但是在Hypervisor的设计当中不使用互斥信号量，因为互斥量的使用会破坏不同VM间的隔离性（比如导致一个VM影响到另一个VM的工作方式）。

因此设备虚拟机化最合适方法就是创建一个分离的安全I/O VM，该VM独占该设备，并为每一个申请访问它的用户VM提供服务。使用这种模型每个用户VM通过向I/O VM发送请求来访问真实的设备。在虚拟设备的底下，Hypervisor提供必要的机制来传递这种请求，因为各个VM是隔离的，如图4所示。

以上五点是设计一款高效裸机虚拟机的核心技术，当然还有其它的一些模块也需要我们去研究和设计，比如VM之间、VM和Hypervisor间通信机制，以及VM异常监控等，Hypervisor的结构如图5所示。

3.  采用Hypervisor的优势

在可靠性和安全性要求比较强的嵌入式系统中采用Hypervisor计时的，有以下几点优势：

(一) VMM可以在同一物理设备上并行运行多种操作系统，一个典型的应用是在Hypervisor构建的虚拟平台上同时运行提供实时任务的RTOS(如vxWorks,ReWorks等)和非实时任务的GPOS（如Linux或Windows）。既解决了通用操作系统实时性的不足，又解决了RTOS应用不够丰富的劣势，如图6所示。

(二) 通过虚拟化可以把不同子系统封装到虚拟机中，比如驱动程序、网络协议栈或者文件系统等内核组件可以直接运行在VM上，其它的子系统可以共享该组件，提高了系统的安全性和代码的复用率。一旦其中一个子系统崩溃或者被攻击，将不再会影响到其它子系统。例如移动手机终端，其通信协议栈非常关键，一旦该协议栈被攻击者成功进入，这台手机就可能干扰整个无线网络，在极端的情况下会导致整个通信网络的瘫痪。同样一个加密子系统也需要极高的安全保护，来保证加密信息不被窃取。但是对于现代的嵌入式操作系统来说，越来越庞大的代码量使得其安全隐患越来越多，由于其允许使用者下载和运行程序，这样的话一旦某个应用的某个缺陷被攻击者作为攻击的切入点，就将导致整个系统的崩溃。比如缓冲区溢出就是一种常见的网络攻击手段，其原理是利用用户程序对缓冲区的超界访问，从而访问到系统关键数据和程序，从而能够窃取系统的控制权。在没有使用虚拟化技术的系统里如图7左，缓冲区溢出攻击一旦成功，整个操作系统已经暴露在入侵者的面前，入侵者将能完全控制整个系统资源，访问所有的关键模块。

如果入侵者攻击使用了虚拟化架构的系统，如图7右边所示，虽然入侵者通过应用程序的缺陷侵入了操作系统的用户交互界面，但该操作系统只负责与用户进行交互。由于 Hypervisor存在，攻击者只能控制被攻击的操作系统，而不能控制运行于虚拟化系统内的其它 OS。这样就保证了攻击造成的损害被降到了最低。

(三) Linux是一个经常被使用的高级操作系统。它的优点就是免费且有一个庞大的开源社区支持。Linux遵照GPL的License发布，它要求任何由Linux衍生出来的代码都要遵照同样的license发布，也就意味着开源。这对于商业开发来讲就是一个两难的取舍，既想使用免费的系统又需要保护商业机密。通过虚拟化技术可以实现 lisence的隔离，图9所示Linux运行于相互隔离的虚拟机中，在 Linux 中用使用驱动桩，而把真实的驱动实现在另外的虚拟机中，从而实现了lisence的隔离。

(四) 虚拟化技术实现了软件和硬件的松散耦合，这样发布一个新的硬件平台时客户操作系统只需要做极少的更改就可以移植到一个新的平台；另一方便那些需要维护周期长的系统，比如舰载系统，一般的周期至少是10年。在此期间有可能原来的硬件平台已经停产或者系统已经停止维护，使用虚拟化技术可以为其提供一个稳定的运行环境。

(五) 另外一个趋势也使虚拟化技术更具吸引力，即制造技术的改进，提高了处理器的顺序执行性能。由于物理空间上的限制，CPU的设计者通过在一个芯片上添加多个处理器核心，使得处理器由原来的仅仅提高单线程的执行性能，转换到提高多线程的执行性能。这也使得系统设计者可以将原来运行在多个节点上的应用，移到单个芯片上运行。然而这种整合面临着一个新的工程问题，因为过去的任务都带有不同的安全级别,这些不同的安全级别应用运行在不同的硬件组件上，原先的这种硬件架构使得非关键应用子系统的故障不会影响到关键应用子系统，但这种应用方式浪费了大量的处理器资源，在当前的硬件平台是不可取的。

以IEC61508标准为例，该标准基于系统故障发生时的严重程度，定义了不同的系统完整性级别SIL(System Integrity Level)用以描述系统的安全性。在SIL4的系统中不管是时间域的故障，还是空间域的故障都会导致人生命财产的损失，以及设备功能的损坏。然而，一个SIL1的应用所引发的故障，除了导致系统的不正确的服务外，不会有其它进一步的损失。一个SIL4的系统必须确保其每小时发生故障的概率小于10^-9，这需要系统具有非常严苛的设计和严苛的验证方法，而对于SIL1应用，通常的测试方法就足够了。来自安全认证部门的重要需求是：或者同一平台的所有应用达到这些应用中SIL基本最高的那个应用所在的安全级别；或者彼此保证有“足够的隔离”措施，使得彼此之间不会存在无意干涉。

在前一个情况，如果所有的应用被整合到同一个处理器上，那边认证安全关键应用的潜在需要是必须对非关键应用进行正式的安全认证，这将导致高昂的开发成本，如果应用是由第三方提供，那么这种安全认证是不现实的。并且在像汽车和航空器应用中，对设备重量和能耗也有着很苛刻的限制。基于虚拟化技术的“足够隔离”概念立足于特定应用程序执行域，使得不同安全级别的应用相互隔离，降低了认证成本，同时又使得系统具有Safety和Security方面的安全性。这也是基于虚拟化技术的分区实时操作系统，比如VxWorks MILS、INTEGRITY®-178B RTOS、Lynx、L4系列的衍生版本(比如OKL4，SEL4等)，越来越被人们重视的原因。

5. 基于Hypervisor开放安全平台

采用Hypervisor来搭建可以搭建一个具有高安全特性的集成开发平台，如图9所示。

上图的底部是硬件平台提供的设备，运行在这些设备之上的是Hypervisor，Hypervisor把每一个VM看出一个虚拟平台，实现各个VM间的强制隔离。系统VM是集成开放平台的核心部分，该部分为应用VM提供通用的服务。我们可以把额外的功能（比如I/O设备驱动以及网络协议栈）放置到VM中，而不是集成为Hypervisor的一个子系统。可以确保Hypervisor子系统极小的代码量，以保障频繁上下文切换的高效性，把把设备驱动和相应的管理模块放置到隔离的VM中，可以提高集成开放平台的可靠性和安全性，并且如果将来需要扩展新的通信模块到集成开发平台，我们只需要修改相应的VM，Hypervisor层则不需要修改。

进一步完善Hypervisor的功能，比如VM间、以及VM和Hypervisor间的高效通信机制研究；进一步研究Hypervisor对各个VM的异常监控诊断机制，当某个VM出现异常时Hypervisor可以及时处理，以确保该VM的故障对整个软件平台的影响降到最低。另外，随着低功耗多核处理器在嵌入式设备上的广泛使用，使Hypervisor支持多核处理器也是未来研究热点。最终我们希望以Hypervisor为基础推出开放安全的集成软件平台，使其在可靠性和安全性要求非常高的嵌入式设备中发挥其技术优势。

参考文献

[1] http://en.wikipedia.org/wiki/Hypervisor

[2] Alfons Crespo, Ismael Ripoll, Miguel Masmano: Partitioned Embedded Architecture Based on Hypervisor: The   XtratuM Approach. EDCC 2010: 67-72

[3] M.Masmano,I.Ripoll,A.Crespo,and J.Metge.XtratuM: a hypervisor for safety critical embedded systems. In Proc. of Real-Time Linux Workshop, 2009.

[4]A.Tavares,A.Didimo, T.Lobo, Rodosvisor — An ARINC 653 quasi-compliant hypervisor: CPU, memory and I/O virtualization.Emerging Technologies & Factory Automation (ETFA), 2012 IEEE 17th Conference on

[5] M. Masmano, S. Peiro, J. Sanchez , J. Simo, A:Device Virtualization in a Partitioned System:the OVERSEE Approach

[6] IA-32 Intel Architecture Software Developer’s Manual Volume 3:System Programming Guide.Chapter 5 Interrupt and exception handing,P.140-157