【Jailhouse 文章】Bao: a modern lightweight embedded hypervisor(2020)

文章目录

• • 1. Abstract
  • 2. Introduction
  • 3. Bao overview
  • • 3.1 设计原则
    • 3.2 平台支持
    • 3.3 TEE 支持
  • 4. 评估
  • • 4.1 Trusted Computing Base
    • 4.2 Performance Overhead
    • 4.3 Interrupt Latency
    • 4.4 cache 着色

1. Abstract

虚拟化技术是混合关键性嵌入式系统的关键支持技术，KVM或Xen等开源虚拟机管理程序设计之初并非为实时嵌入式平台量身定制，而是依赖于Linux。Bao 是一个轻量级的开源嵌入式管理程序，旨在提供强大的隔离和实时保证，与 Jailhouse 类似的是，它也利用了硬件虚拟化支持功能，与 Jailhouse 不同的是，它不依赖于 Linux。目前支持 ARMv8 和 RISC-V。Bao 是从零开发的，旨在提供最小的全新和工业级解决方案，并让学术界和工业界共同应对现代汽车和工业系统的挑战。

2. Introduction

使用虚拟化技术可以在高性能嵌入式系统中部署混合关键系统，并且已经在汽车和工业自动化等领域中得到了广泛的应用，这些领域中需要满足tight size、weight、power、cost(SwAP-C)限制。

在开源领域，KVM 或 Xen 等 Hypervisor 是首选解决方案，这些 Hypervisor 最初是针对服务器领域涉及到，目前已经能够在嵌入式平台进行使用，但是它们不能完全适合嵌入式平台所要求的实时性。此外，从安全角度来看，它们通常包含大型可信计算库（TCB），因为它们通常依赖于操作系统，通常是 Linux，运行在特权虚拟机（VM）上，为剩余的虚拟机管理服务。这些虚拟机管理程序经常通过仿真或半虚拟化机制提供一组丰富的虚拟化服务（例如虚拟网络），从而增加了超级调用的数量并导致了更大的 TCB 和更多的攻击漏洞[5]。

除了传统的 Hypervisor 方案，静态分区虚拟机管理程序亦成为了另一种混合临界系统的可行解决方案。该方案在初始化时对所有系统资源进行静态分区，方法是直接且独占的将每个资源分配给单个分区。通过硬件虚拟化扩展，这种方法可以将 TCB 和虚拟化开销（例如 VM 中断延迟、VM 启动时间）降至最低。该方案的典型实例有 Jailhouse，但其依靠特权 Linux VM 来引导系统和管理其它 cell。

尽管静态分区架构提供了高度的隔离和确定性保证，但存在仍未解决的安全问题。首先，对于共享的资源（例如 LLC、内存控制器），通过增加访问抖动性，能够损害系统的确定性和可用性，常见的缓存攻击技术有 Prime+Probe，因为会使 VM 受到拒绝服务（Dos）攻击。已经提出了缓存分区技术（例如缓存着色）或者内存带宽预留来缓解这些问题。其次，静态分区不能支持多个相互隔离的可信执行环境（TEE），TEE 通常由 ARM 的 TrustZone 等硬件安全技术支持，并且基于 TrustZone 的 TEE 中普遍存在安全漏洞，这种双世界硬件隔离本身并不是最终解决方案。

本文介绍了 Bao，一种开源的静态分区Hypervisor架构，本文主要围绕 Bao 的设计进行介绍，同时对其 TCB 和虚拟化开销进行评估。

3. Bao overview

Bao（来自普通话baohu，意为保护）是一个面向安全的轻量级裸机管理程序，它的设计目标是混合临界系统，因此，它的主要功能是提供故障控制和保证系统实时性。

Bao 的架构如图，资源被静态分区并专门分配给每个 VM：1. 内存仅在初始化时分配 2. guest IO 请求直达硬件（pass-through） 3. 虚拟中断直接映射到物理中断 4. 虚拟 CPU 一一对应到物理 CPU，无需调度管理程序。由于在此类系统中 VM 经常需要相互交互，因此管理程序还为 VM 间通信提供了简单的原语。这种机制基于静态共享内存和通过超级调用触发的虚拟机间中断形式的异步通知。 Bao 允许多个 vCPU 在同一个 pCPU 中执行。

3.1 设计原则

Bao 是围绕一组核心原则设计的，这些原则指导其实施和未来方向：

1. 轻量级与简单性

代码实现尽可能简单，因此，Bao 需要借助硬件辅助完全虚拟化功能。通过尽可能减小代码量和代码复杂性显著降低了虚拟化开销和系统的TCB。对于 Hypercall 接口，其应该只提供必要的服务。

2. 最小特权

要求每个物理 CPU 都有一个私有地址空间，只映射所需的物理页面，因此，每个物理 CPU 仅管理分配给它的虚拟域和 vCPU 结构，无法访问不属于它的 VM 信息。管理程序无法直接访问虚拟域的物理内存，要求所有超级调用参数都通过处理器寄存器中的值传递，而不是通过引用传递。最后，只有基本的虚拟化机制在 hypervisor 的特权模式下执行，所有其他功能都必须迁移到 VM。

3. 彻底隔离

尽管静态虚拟化提供了直接的逻辑隔离，但虚拟机仍然通过共享的微架构状态进行交互。Bao 使用了缓存着色机制，该机制考虑了分配给给定 VM 的颜色。此外，管理程序本身可以配置为仅使用某些颜色。然而，缓存着色技术有几个缺点，例如，内存碎片。

3.2 平台支持

Bao 仅支持 64 位架构，目前支持 ARM-v8，RISC-V 上还未成熟，没有可用的硬件平台，仅在 QEMU 上运行。目前：Bao 被移植到两个 ARM-v8 平台：Xilinx ZCU 102/104、Hikey 960(Kirin 960)。Bao 支持的 os：FreeRTOS、裸机应用程序、Erikav3 RTOS、Linux 和 Android。

除了启用其活动日志输出的简单串行驱动程序外，Bao 不依赖于特定于平台的设备驱动程序。要移植到新平台，只需要一个简单的描述，详细说明可用 CPU 的数量、可用内存及其位置。出于这个原因，Bao 依赖供应商提供的固件或通用引导加载程序来执行低级硬件初始化、管理以及管理程序和内核映像加载。

在 Arm 架构中，GIC（通用中断控制器）是主要的中断仲裁器和路由器，由中央分配器和每个 CPU 接口组成。在当前支持的平台中，可用的 GICv2 提供了一些虚拟化支持。但是，所有中断仍然转发到管理程序，管理程序必须在目标 VM 中重新注入中断。此外，尽管 CPU 接口完全由硬件虚拟化，但必须使用陷阱和仿真方法来访问分配器。较新的 GICv4 将为 VM 提供直接中断传递。

3.3 TEE 支持

Bao 允许多个 vCPU 映射一个 pCPU，尽管 vCPU 始终固定到单个 pCPU。对于配置中的每个 VM，可以定义一组辅助 VM。辅助虚拟机旨在允许多个隔离环境在单个硬件分区中执行。为了与其最小化设计原则保持一致，没有添加调度程序：仅当当前活动的 vCPU 显式调用其辅助 VM 之一时才会调度 vCPU，并且稍后，被调用的 vCPU 只能将执行交给其调用者。这两个操作都是通过两个具有非常低级语义的简单超级调用发出的。此外，不存在 vCPU 迁移：只能调用分配给同一 pCPU 的 vCPU。我们将此过程称为 vCPU 或 VM 堆栈，因为 vCPU 以 FIFO 方式“调度”，就像在过程调用和返回期间在堆栈上创建和销毁堆栈帧一样。

如图所示，拥有更高权限的 TEE VM，而操作系统将使用 yield 超级调用来调用安全服务。

如图，使用“监控”虚拟机来调度 OS 和 TEE 虚拟机，模仿 TrustZone 的双世界架构。

4. 评估

本次评估针对的是 Xilinx ZCU104 板，该板采用 Zynq-US+ SoC，具有运行频率为 1.2 GHz 的四核 Cortex-A53、每核 32K L1 数据和指令高速缓存以及共享的统一 1MB L2/LLC 高速缓存。Bao 是使用带有 -O2 优化的 Arm GNU 工具链 8.2.1 版编译的。

4.1 Trusted Computing Base

我们使用源代码行 (sLoC) 和二进制大小作为指标来评估 TCB。 如图显示了 C、汇编代码和总代码行数。如图按部分显示了为目标平台构建 Bao 的最终二进制大小。总共约 5.6 KSLoC 和约 59 KiB 的最终二进制文件反映了 Bao 的实现实现的低复杂度和小 TCB。

4.2 Performance Overhead

MiBench Embedded Benchmark Suite [16] 用于评估在 Bao 上运行的 Linux 客户机的虚拟化性能开销。 如图显示了获得的结果，本文认为这些开销主要是由于两阶段地址转换造成的。

4.3 Interrupt Latency

为了测量中断延迟，我们使用了一个定制的裸机客户机，它连续计算在以 100 Hz 频率编程的定时器中断上观察到的延迟。将本地执行与托管执行进行比较，如图显示平均延迟增加了约 430 ns，标准偏差增加了约 40.5 ns。这表明在强制中断重新注入的情况下，GICv2 会产生巨大的开销。此外，最坏情况的延迟也显着增加。由于该值仅在我们实验的第一次测量中观察到，我们认为这是用于注入中断的管理程序代码的指令缓存上强制缓存未命中的结果，这表明其他客户机执行可能会显着影响 VM 中断通过强制驱逐这些缓存行来延迟。虽然我们还没有通过经验验证这一点，但我们相信通过使用缓存着色将缓存分区专用于管理程序，可以最大限度地减少这种影响。

4.4 cache 着色

为了验证缓存着色机制在通过 LLC 避免 VM 干扰方面的正确性和有效性，我们从安全角度出发，使用来自其中一个 VM 的简单缓存 Prime+Probe，同时改变“受害者”访问的缓存行数虚拟机。如图描述了评估通道的通道矩阵 [17]。此热图表示当访问一定数量的高速缓存行时测量给定探测时间的概率。观察到的对角线趋势表明，给定探测时间可以很容易地推断出受害者访问的线路数。

我们在启用着色的情况下重复实验，将一半的 LLC 分配给每个 VM。结果如图显示了生成的通道矩阵，该矩阵显示探测时间没有变化，与受害者访问的线路数无关。这证实了缓存着色在划分 LLC 和避免 VM 之间通过它的信息泄漏方面的有效性。

暑期编程PK赛 得CSDN机械键盘等精美礼品！