【Jailhouse 文章】Look Mum, no VM Exits
时间:2022-08-24 09:30:01
Ramsauer R, Kiszka J, Lohmann D, et al. Look mum, no VM exits!(almost)[J]. arXiv preprint arXiv:1705.06932, 2017.
本文提出了一个基础 Linux 与操作系统无关的分区Hypervisor —— Jailhouse,它将 Linux 与严格隔离的系统相结合。本文的设计目标是尽量减少代码量 Hypervisor 对 GuestOS 的干涉。Jailhouse 直接分配硬件 GuestOS,从而引导复杂的硬件处理问题Hypervisor转移到一般操作系统(GuestOS)。Jailhouse 在不模拟或半虚拟化的情况下,建立隔离域,直接访问物理资源。Jailhouse不仅保留了 Linux 操作系统的通用性也利用其简单的优点,使隔离域中的安全关键和实时关键工作负荷更容易运行。
文章目录
-
- 1. Introduction
- 2. Related Work
- 3. Static Hardware Partition
-
- 3.1 Jailhouse Philosophy
- 3.2 Support
- 3.3 Practicability
- 4. EVALUATION
- 5. DISCUSSION
- 6. CONOLUTION AND FUTURE WORK
1. Introduction
安全关键和非关键产品的制造商倾向于将不同关键级别的组件分成不同的硬件,如不同的物理CPU执行不同关键级别的任务。在传统的混合临界环境中,单个控制任务与特殊的物理控制硬件绑定,典型的物理控制器是可编程逻辑控制器(PLC),其中一辆车可以包含几十到一百个不同的控制器。将这些系统集成到单个硬件控制器中是一种架构趋势[4],因为它不仅可以提高软件的可维护性,还可以降低整体硬件的成本。使用本文的方法 CPU 虚拟扩展技术创造执行环境,利用静态分区技术划分硬件资源,将现有程序移植到严格隔离的执行领域。
Jailhouse 通过向系统和 I/O 将虚拟屏障插入总线,对称多处理 (SMP) 系统转换为非对称多处理 (AMP) 系统。从硬件的角度来看,系统总线仍然是共享的,但是GuestOS(囚犯)只能使用一些物理硬件,就像被囚禁在牢房里一样。
Jailhouse 由启动操作 Linux 启用系统内核模块。Jailhouse 根据系统配置重新分配所有硬件资源 Linux,并将 Linux 提升到虚拟机状态(虚拟机)。Jailhouse 的 Hypervisor 作为虚拟机监视器的核心 (VMM)。该方案不适用于传统方案 Hypervisor 分类 [8] —— 可视为 Type-1 和 Type-2 Hypervisor它就像裸机 Hypervisor 在原始硬件上运行,没有底层操作系统,但如果没有 Linux 提供初始硬件作为助手的功能,Jailhouse 仍然无法运行。Linux 用于引导加载程序,但不用于管理系统。Linux 用于指导加载程序,但不用于管理系统。其他目的是管理硬件资源,并禁止它们 GuestOS 系统直接访问实时分区(例如,PikeOS [10])不同,Jailhouse 只支持直接硬件访问。Jailhouse 未使用复杂耗时的(半)虚拟化 [2] 方案来模拟设备驱动程序并共享物理硬件资源,而是采用类似 exokernel 的方法 [7]因为它只提供隔离(通过使用虚拟化扩展),不提供调度程序或虚拟 CPU。
本文主要内容:
- Jailhouse 运行在多个架构上的架构功能齐全、非调度、实时、静态分区和开源Hypervisor。
- 运行混合关键应用程序样本。
- 延迟虚拟机 Hypervisor 激活的优点。
- Nvidia Jetson TK1 典型的微基准测试中断系统
2. Related Work
虽然 Hypervisor 通常优化桌面和企业领域的高吞吐量和最佳性能,但实时嵌入式系统的虚拟化解决方案,特别是低延迟、确定性计算周期和实时维护能力,许多嵌入式虚拟机 Hypervisor 采用经典虚拟化的既定方法:过度虚拟化硬件和半虚拟化 [2] 或设备仿真,以及 GuestOS 调度。
克雷斯波等人介绍 XtratuM [5] 嵌入式 Hypervisor。他们的方法侧重于航空电子指南和规范的设计约束。他们专注于 Xtratum 内存管理、时钟和定时器管理、中断管理、功能丰富的超级调用接口和自己的调度程序。XtratuM 是成熟的虚拟机Hypervisor。
PikeOS [10] 允许不同的执行 GuestOS 或本地任务。运行的客户操作系统,PikeOS 使用半虚拟化和硬件辅助虚拟化,但也允许直接使用 I/O 访问。调度应用程序,PikeOS 结合时间和优先驱动的调度,并尽最大努力使用非关键任务。
实现时空隔离,Hypervisor 并不总是需要所有的虚拟扩展功能。[16] 通过利用 ARM TrustZone 技术在单个 CPU 上与 Linux 实时操作系统并行运行。他们的方法是快速中断实时关键设备 (FIQ) 保持实时功能。与常规 IRQ 这些中断直接到达实时操作系统 Hypervisor 安全世界的执行。正常中断到达与安全世界隔离的非安全世界,只将非安全世界与安全世界隔离。此外,TrustZone 该方法只允许创建两个域。
Quest-V [12] 是 Quest 在几个方面和 Jailhouse 相似。以最少为目的 Hypervisor 静态硬件分区活动。与 Quest-V 相比,Jailhouse 只是一个 VMM,没有实现任何设备驱动程序,这大大降低了其代码库。Quest-V 依靠半虚拟化方案来指导 Linux 内核作为 GuestOS。
与所有这些系统相比,Jailhouse 从 Linux 开始(并利用其大部分硬件的初始化能力),然后使用延迟(或延迟)虚拟机 Hypervisor 激活 [18] 将硬件分区到已经运行的地方 Linux 下。
3. Static Hardware Partition
3.1 Jailhouse Philosophy
如图所示,激活 Jailhouse 包括工作 Hypervisor (HV) 的 Linux 在每个核模块的帮助下完成的 CPU 执行完 HV 启动代码后,Linux 继续作为J ailhouse 的 Guest 运行(一个 cell),即 root cell。
Linux 硬件支持完善完善的操作系统,Jailhouse 利用这一优势 Linux。Jailhouse 非典型的延迟激活过程具有相当大的实际优势,即大多数硬件初始化完全下沉 Linux,并且 Jailhouse 虚拟化扩展可以完全集中在管理上。与 exo-kernel [7] 方法类似,Jailhouse 是一个 exohypervisor。允许硬件设备的直接分配 Linux 继续像以前一样执行。不同于其它分区方法(如[12]),Jailhouse 没有特定的设备驱动程序。
Jailhouse 假设物理硬件资源不需要 GuestOS 之间共享。为了创建额外的域(称为non-root cell),Jailhouse 从 Linux 硬件资源硬件资源 CPU、内存、PCI 或 MMIO 设备)并重新分配给新域。这包括物理 CPU:cell 配置文件至少包含一个 CPU 以及具有辅助操作系统或裸机应用程序的一定数量的内存 root cell 预加载。
Linux 使选定的 CPU 脱机并调用 Hypervisor,提供描述资源分配的描述 cell 创建新的配置文件 cell。其它资源,如 PCI 设备、内存映射设备或 I/O 端口也可以重新分配给新的 Guest(cell)。Hypervisor 阻止从任何其他域中对这些资源的访问。non-root cell 动态创建和销毁(即资源分配回来)root cell)或重新启动。
由于 Jailhouse 理想的设计理念是,除了管理任务外,它不需要设置和启动所有资源 GuestOS 之后还处于活跃状态,只在访问冲突时拦截:No VM exists!但是,硬件(尚未)完全适合这种方法,所以在目前的硬件中,以下情况仍然需要 VMM 的干预:
- 重新注入中断(取决于架构,中断可能不会直接到达 Guest)
- 拦截不可虚拟化的硬件资源(例如,ARM 上的通用中断控制器 (GIC) 的一部分)
- 访问控制协处理器 CP15 或 ARM 上述电源状态控制接口 (PSCI))
- 模拟某些指令(例如 x86 上的 cpuid)
以下陷阱是不可避免的,并且与本文的概念不矛盾,因为它们仅在jailbreak或cell管理的情况下发生:
- 访问冲突(内存、I/O 端口)
- cell管理(例如,创建、启动、停止或销毁cell)
这些拦截会引入开销和延迟 —— 这是当然的,因为虚拟化是有代价的 [6]。在第四节中,本文示例性地介绍了对一个基本微基准的评估,即中断的额外延迟。
尽管 GuestOS 之间的资源严格隔离,Jailhouse 仍然允许 cell 共享物理页面。除了满足 cell 间通信外,还允许共享内存映射的 I/O 页面,如果需要,这允许从多个域内访问硬件资源。然而,这种并发访问不是由 Jailhouse 仲裁的,需要由 GuestOS 适当地解决。
如图显示了三个 cell 的可能分区系统布局:Linux 根cell(绿色)、一个附加的 Linux non-root cell(蓝色)和一个极简实时操作系统(红色)。cell 之间的通信是通过共享内存区域以及信令接口实现的,这种极简设计在 Hypervisor 中不需要额外的设备驱动逻辑。根据硬件支持,cell 间通信通过 MessageSignaled Interrupts (MSI-X) 或传统中断基于虚拟 PCI 设备实现。GuestOS 可以使用此设备在其上实现虚拟以太网设备。在没有 PCI 支持的系统上,Jailhouse 模拟一个通用且简单的 PCI 主机控制器。
3.2 Support
分区方法允许经过安全认证的操作系统或裸机应用程序在与 Linux 并行的多核系统上运行。值得一提的是,尽管 Jailhouse 支持四种不同的 CPU 架构,超出了许多实验或研究系统所提供的架构,但其极简的方法导致核心部分的代码只有几千行。这简化了认证过程,但允许开发人员专注于重要问题,而无需花费时间提供系统在生命周期内都不会用到的驱动程序。核心代码的简洁是对 Hypervisor 进行形式验证的良好基础,类似于相关系统软件的形式验证 [11]。
Jailhouse 带有自己的 inmate library,允许运行简约的演示应用程序。除了 Linux 之外的几个操作系统已经可以作为 Jailhouse GuestOS 使用(x86 [3] 上的 L4 Fiasco.OC、ARM 上的 FreeRTOS、ARM64 上的 Erika Enterprise RTOS v3)。本文以非常有限的努力成功地为 ARM 架构移植了 RTEMS 实时操作系统。
3.3 Practicability
为了证明本文的方法特别适用于实际应用,本文设计了一个(混合临界)多旋翼控制系统。对此类平台的要求可与许多常见的工业设备相媲美:飞行堆栈是系统中具有高可靠性要求的安全和实时关键部分,负责飞机的平衡和导航。传感器值必须以高数据速率进行采样、处理并最终用于控制转子。对于安全可靠的任务,控制回路必须做出确定性响应。系统崩溃可能会导致真正的崩溃并带来严重后果。
飞行堆栈在 Jailhouse cell 中运行,而非关键任务,例如与地面站的 WiFi 通信或摄像头跟踪,由于可用的 Linux 软件生态系统,可以在非关键部分轻松实现。关键硬件组件,例如 SPI、I2C 或 GPIO 设备,被分配给关键 cell。本文的硬件平台是带有四核 Cortex-A15 ARMv7 CPU 的 Nvidia Jetson TK1,连接加速度计、GPS、指南针和陀螺仪的传感器板。两个物理 CPU 分配给非关键部分,两个物理 CPU 分配给关键部分。
关键域执行具有 Preempt_RT 实时内核扩展的第二个精简 Linux 操作系统。Ardupilot 提供飞行控制,除了板支持之外不需要修改。这意味着现有应用程序可以毫不费力地部署在 Jailhouse 中,并且适用于基于现有组件的实时安全关键系统。
4. EVALUATION
如前所述,Jailhouse 的目标是尽可能减少 VMM 的活动。尽管这在理论上是可能的,但存在 VMM 便会引入额外的延迟 [6],而没有 VMM 则不会存在这些延迟。
为了评估和确定管理程序的(实时)性能,必须考虑几个环境条件。用一个单一的标量来量化管理程序的开销是困难的,甚至是不可能的。由于论文篇幅有限,本文将示例性地详细介绍中断延迟的测量,并描述其他重要的测量。
需要注意的是,此类基准测试并不衡量管理程序的开销,而是衡量管理程序在特定硬件平台上运行时的开销。尽管如此,这些测量仍然可以得出管理程序性能的趋势。
a) 超级调用:管理程序的一个典型基准是超级调用的成本。在 Jailhouse 的情况下,不需要考虑超级调用,因为它们仅用于单元管理目的,并且永远不会出现在热路径中。
b) 共享系统总线:不同的 guests 异步访问内存。尽管在受支持的体系结构上不会发生饥饿,但内存或 I/O 总线的大量使用可能会导致 Guests 显着变慢。虽然这个问题在 SMP 应用程序中是众所周知的,但在异步执行为单核平台设计的多个有效负载时,必须评估其影响。
c) 依赖于架构的陷阱:由于架构限制,Jailhouse 需要模拟硬件平台所必需且无法在硬件中虚拟化的设备(例如,作为 ARM 架构上通用中断控制器的一部分的中断分发器)。根据这些设备的使用情况,必须分析管理程序的影响。
d) 中断延迟:Jailhouse 支持两个版本的 ARM 通用中断控制器,GICv2 和 GICv3 [13, 14]。两种实现都有相同的架构限制:中断不会直接到达 Guest。它们到达管理程序,然后作为虚拟 IRQ 重新注入 Guest。这会造成管理程序中的开销,因为它必须将中断重定向到适当的 Guest,然后切换特权级别。
本文的自动测量设置包括一个 Nvidia Jetson TK1(四核 Cortex-A15 @2.32GHz)作为目标平台,以及一个用于执行实际测量的 Arduino Uno 硬件。
为了测量这种延迟,本文将裸机延迟(即没有管理程序的最小延迟)与存在管理程序时的延迟进行比较。Arduino 会定期触发目标板上的 GPIO 引脚,从而导致中断。非根单元的唯一任务是通过切换另一个 GPIO 尽快响应中断。因此,本文实现了一个使用 Jailhouse 自己的 inmates library 的简约 GuestOS。为了最小化响应的代码大小以使其尽可能快,用于切换 GPIO 的指令直接用汇编程序编写在中断向量表中。没有管理程序的测量代表所选硬件平台可实现的最小延迟。存在和不存在虚拟机管理程序的延迟差异衡量了当虚拟机管理程序和其他 Guest 异步访问系统总线时引入的延迟。Uno 的确保以 62.5ns 的分辨率进行精确测量。为了验证测量结果,本文使用示波器手动测量的延迟验证了样本测量值。
本文在几个条件下重复测量(例如,将负载放在其他客户机上以测量对共享系统总线的影响)并给出算术平均值以及标准偏差和最大延迟。每次测量运行四个小时,并以 10Hz 和 50Hz 的中断频率重复,以确定测量频率的影响。结果可以在表中找到。前两行显示了在没有管理程序存在的情况下测量的最小中断延迟,与其他测量的差异表示管理程序引入的开销。
虚拟机管理程序引入的延迟并不明显取决于中断频率,而是取决于相邻 Guest 的利用率。这种影响是由共享系统总线引起的:管理程序想要访问调度中断所需的内存,而其他 Guest 异步访问同一总线。
平均而言,中断延迟约为 810ns,偏差很小。尽管如此,异常值仍会导致近 5µs 的延迟。与典型工业通信总线系统的周期时间相比,最大延迟对于许多应用来说是可以接受的。
5. DISCUSSION
Jailhouse 的简约设计方法产生了可管理数量的源代码行 (SLOC)。 这对于学术角度的形式验证和工业角度的系统认证都是至关重要的因素(本文意识到,除了 Linux 内核之外,还需要大量软件链(例如 UEFI 固件代码、引导加载程序等)来进行引导过程,并且在某种程度上需要在此类认证中加以考虑)。
Jailhouse 总共包含用于四种不同架构的近 30k SLOC。这包括管理程序核心、示例代码、内核驱动程序以及用户空间工具和工具脚本。代码的大部分是独立于架构的。跨所有架构共享的公共关键管理程序核心代码总计不到 3.4k SLOC。x86 的体系结构相关代码约为 7.4k SLOC,并同时实现了 Intel 和 AMD,以及 ARM(ARMv7 和 ARMv8)约为 5.4k SLOC。
许多系统研究都是从零开始的,并且在重新实现现有设备驱动程序上花费了巨大的精力。但是,缺少设备支持仍然是其实用性的主要障碍。 Quest-V 超过一半的源代码行(≈140k SLOC 中的 70k SLOC)是设备驱动程序。XtratuM 具有近 27k 的 SLOC,比 Quest-V 更轻量级,并且仅实现了用于调试输出的基本驱动程序。尽管如此,Quest-V 和 XtratuM 的公开版本目前仅支持 x86 架构。
Jailhouse 故意不遵循经典的虚拟化方法,但其设计通常不会消除这些技术的使用。这为将 Jailhouse 用作实验系统平台提供了可能性,该平台允许将注意力集中在实际问题上,而不是从头开始重新实现基础。Jailhouse 是调查 AMP 工作负载下的硬件和软件行为的理想平台。此外,它为在原始硬件上执行类似数字信号处理 (DSP) 的工作负载提供了一个方便舒适的环境。
现代多核系统已经提供了足够的物理 CPU,使得许多实际嵌入式用例无需在管理程序中进行调度。事实上,实时嵌入式管理程序 [5] 的许多基本要求,例如实时调度策略、高效上下文切换或确定性管理程序调用,甚至不需要在 cell 配置文件中解决。由于 Jailhouse 不会虚拟化 CPU、过度虚拟化硬件或进行分区调度,因此不会出现昂贵的分区上下文切换或调度问题 [23]。超级调用仅用于管理目的,而不用于调节对共享硬件的访问。
根据中断系统和架构,中断可能会到达管理程序。在这样的平台上,向 Guest 重新注入中断是管理程序的一项常见工作,它会引入意外的额外中断延迟。对于支持中断重映射的 64 位 x86 架构,这个问题已经得到解决,并且将在未来实现 GICv4 [14] 规范的 ARM 架构中得到解决,这有利于本文的最终目标,即 no VM exists!。
然而,硬件设计造成的陷阱是不可避免的。在当前的 ARM 架构上,中断分配器必须是虚拟化的。Varanasi 和 Heiser [22] 假设这不会导致性能问题。在本文的实现过程中,本文观察到带有 Preempt_RT 实时补丁的 Linux 内核大量使用了中断分配器,这导致了管理程序的高活动。此类问题应通过适当的硬件设计来解决,以便能够执行未修改的 Guest。
6. CONOLUTION AND FUTURE WORK
静态分区管理程序技术是一种用于嵌入式实时虚拟化的有前途的方法,因为他们最大限度地减少与 GuestOS 交互。与半虚拟化技术相比,直接将硬件分配给 GuestOS 允许运行未经修改的应用程序,而没有管理程序开销。极简的虚拟机管理程序核心简化了认证工作。通过以访客身份执行标准操作系统,本文还最大限度地减少了移植现有传统有效负载应用程序所需的工作量。通过实现一个复杂的演示平台,本文成功地展示了硬件分区的实用性。
虽然当前硬件提供的标准虚拟化扩展似乎足以直接实现本文和许多其他方法,但实际硬件存在许多限制,这些限制可能完全破坏基于分区和虚拟化的方法的优势和保证。本文未来的工作将解决出现的问题并专注于评估管理程序的性能。