2.2.2 基于RTOS扩展的Hypervisor实现

基于RTOS扩展的Hypervisor实现是指在传统操作系统的基础上添加虚拟化功能，以支持多个虚拟机的运行。该设计模式的优点包括更好的兼容性和更高的灵活性，可以根据应用需求动态地分配和管理资源。

在传统的PC Hypervisor架构中，几乎所有的Hypervisor都遵循集中式开放架构，包括裸机Hypervisor（即Ⅰ型Hypervisor，比如Xen）、被托管的Hypervisor（即Ⅱ型Hypervisor，比如VMware Workstation）。由于Hypervisor围绕拥有硬件资源并管理分区的中央“主操作系统”（GPOS或者RTOS）构建，因此它们是集中式的；同时也是开放的，因为它们能在分区中托管任何操作系统。很多Hypervisor都是由RTOS扩展而来的，比如应用在航电领域的VxWorks653 Hypervisor是由VxWorks-5.5系统扩展而来的。使用这类Hypervisor通常意味着用户必须采用供应商裁剪定制的RTOS，即使所有的客户操作系统都是完全开源的。这样做通常有以下3个原因。

1）它使得Hypervisor可以利用供应商现有的RTOS BSP（Board Support Package，板级支持包），降低了BSP的开发成本。

2）从拥有所有CPU资源、内存和外围设备的RTOS内核上创建Hypervisor要比重新设计并实现分离内核的Hypervisor容易得多。

3）供应商RTOS工具链（IDE和编译器）通常与Hypervisor打包在一块，便于销售供应商的产品。

基于RTOS扩展的Hypervisor的实现代码更多。它通常包含设备驱动程序、动态内存分配和shell访问，以访问用于创建、查看和启动分区的命令解析器。RTOS将在内核同时调度系统任务和分区任务，同时RTOS内核可能还具有虚拟终端，以便访问分区客户虚拟控制台、虚拟网络服务，并允许分区共享物理网络接口。但是这类代码通常具有安全性问题（比如可能存在缓冲区溢出漏洞），这在SKH实现中是不可接受的。

基于分离内核的Hypervisor和基于RTOS扩展的Hypervisor唯一的通用代码是配置分区的代码。在基于分离内核的Hypervisor实现中，配置分区的代码是引导过程完成的。出于安全性考虑，配置分区的代码不放在SKH内核当中，这就是分离内核的分区资源是静态配置的，一旦启动完成后就不可以更改的原因。

在基于RTOS扩展的Hypervisor中，所有这些额外代码都代表着安全风险的攻击面。处在特权模式下的Hypervisor内核代码一旦出错，将具有破坏整个系统的风险。另外，Hypervisor代码量比较大，已通过形式化证明保证其正确性极具挑战。虽然这些额外代码很有价值，并且提供了有用的功能，但是根据极小化设计原则，这类功能子系统不能处于Hypervisor之中，而应放到客户分区中实现。这种在分离内核中仅包含最少代码的方法遵循了最小特权原则（Principle of Least Privilege）。操作系统微内核的设计也遵循相同的设计模式，即将辅助性组件从内核空间放到用户空间中实现。

---

提示：虽然在许多方面，SKH和微内核（Micro-Kernel）非常相似，两者都有最少的代码量，并且都支持最小特权原则的体系结构。然而，这两种技术的实现目标是不同的，因此两者的最小特权运行时体系结构的构建方式也不同。

微内核的目标是提供一个比宏内核（Monolithic-Kernel）的操作系统（比如Linux）更安全的运行时环境，而分离内核Hypervisor的目标则有所不同，因为它不是一个操作系统。SKH不进行集中的系统控制，它将本地硬件资源映射到分区空间，提供给分区客户操作系统使用，并由客户操作系统为应用程序提供运行时环境。微内核操作系统需要大量的IPC（Inter-Process Communication，进程间通信），安全性不容易评估，并且应用程序之间的隔离薄弱；而SKH提供了系统资源配置模型，该模型将所有执行上下文的运行时环境约束在一组显式的物理资源防篡改的分区环境中，使得SKH内核的安全性更容易评估。另外，微内核操作系统是一个主操作系统，而SKH是一种分布式的同构框架，没有主操作系统的存在；SKH提供的多分区运行时环境可以组合并协同工作，并且SKH内核通常也是采用单体式实现的。

---