cms网站内容管理系统,wordpress投稿分成,彩票资料网站怎么做,安庆市建设银行网站Bao#xff1a;一种用于现代多核嵌入式系统的轻型静态分区管理程序 个人学习过程中 Bao Hypervisor 论文翻译#xff08;借助翻译工具个人校对#xff09;#xff0c;仅供学习使用#xff0c;由于个人对一些技术专有名词不够熟悉#xff0c;翻译不当的地方欢迎指出 论文地…Bao一种用于现代多核嵌入式系统的轻型静态分区管理程序 个人学习过程中 Bao Hypervisor 论文翻译借助翻译工具个人校对仅供学习使用由于个人对一些技术专有名词不够熟悉翻译不当的地方欢迎指出 论文地址https://drops.dagstuhl.de/opus/volltexte/2020/11779/ github仓库https://github.com/bao-project/bao-hypervisor 摘要
鉴于现代嵌入式系统日益复杂和混合临界性虚拟化成为一种实现强大空间和时间隔离的自然解决方案。广泛使用的系统管理程序如 KVM 和 Xen在设计时并没有考虑到嵌入式的约束和需求。由 Jailhouse 开创的静态分区架构似乎解决了嵌入式的问题。然而Jailhouse 仍然依赖 Linux 来启动和管理其 VMs。在本论文我们提出了 Bao管理程序这是一个针对 Armv8 和 RISC-V 平台的静态分区架构的最小、独立和干净的实现。关于大小 size 、启动 boot 、性能 performance 和中断延迟 interrupt latecy 的初步结果表明这种方法只产生最小的虚拟化开销。Bao 将很快公开希望能让业界和学术界参与改善 Bao 的安全性、保障性和实时性。
关键词Virtualization, hypervisor, static partitioning, safety, security, real-time, embedded systems, Arm, RISC-V
1、 介绍
在诸如汽车和工业控制等领域过去几年来功能需求的数量持续增加。随着越来越复杂且计算功耗大的应用程序数量增加对高性能嵌入式系统的需求也在同步增长。这导致了一种范式转变从使用运行简单裸机应用程序或实时操作系统RTOS的小型单核微控制器转向了强大的多核平台具有复杂的内存层次结构并能够承载功能丰富的通用操作系统GPOS。与此同时市场压力要求最小化体积、重量、功耗和成本促使将多个子系统整合到同一硬件平台上。此外这些子系统通常采用混合临界性MCSs系统的形式通过集成具有不同临界级别的组件。例如在汽车系统中网络连接的娱乐信息系统经常与安全关键的控制系统一起部署 。因此在整合混合临界性系统时必须非常小心以平衡安全性和安全性所需的隔离与资源共享的冲突要求。
虚拟化是桌面和服务器中已经成熟的技术它成为实现整合和集成的自然解决方案。它需要最少的工程投入来支持传统软件同时保证虚拟机VMs之间的分离和故障隔离。将面向服务器的虚拟化程序例如 Xen 或 KVM适应嵌入式架构主要是 Arm已经取得了相当的成功。然而考虑到目标系统的混合临界性性质直接的逻辑隔离已被证明不足以满足严格的嵌入式约束和实时要求。此外这些嵌入式虚拟化程序通常依赖于大型 GPOS通常是 Linux来引导、管理虚拟机或提供各种服务例如设备模拟或虚拟网络 。从安全性和安全性的角度来看这种依赖膨胀了系统的可信计算基础TCB并拦截了安全引导机制中的信任链从而扩大了系统的攻击面。此外由于这些操作系统的大小和单olithic结构这种紧密耦合也阻碍了部署此类虚拟化程序的系统的安全认证过程。
Siemens 的 Jailhouse 静态分区虚拟化程序架构最近在学术界和工业界的混合临界性系统中越来越受欢迎。该架构利用硬件辅助虚拟化技术使用最小的软件层静态分区所有平台资源并将每个资源专门分配给单个 VM 实例。它假设不需要在客户之间共享硬件资源。由于每个虚拟核心都静态固定到单个物理 CPU因此无需调度程序也不提供复杂的语义服务进一步降低了大小和复杂性。尽管可能阻碍高效资源使用的要求但静态分区允许更强的隔离和实时性保证。尽管 Jailhouse 遵循其设计理念但它仍然依赖 Linux 引导系统并管理其“cell”面临其他虚拟化程序同样存在的安全问题。
尽管静态分区方法提供了强大的 CPU 和内存隔离但这仍然不足以满足许多微架构资源例如最后级缓存、互连和内存控制器在分区之间保持共享。由此产生的争用导致缺乏时间隔离影响性能和确定性。此外这可能被恶意虚拟机利用通过增加对共享资源的消耗来实施 DoS 攻击或者通过隐含的时间侧信道间接访问其他虚拟机的数据。为解决这个问题操作系统和虚拟化程序级别已经提出并实现了诸如缓存分区通过锁定或着色或内存带宽保留等技术。
本文介绍了 Bao这是一个从头开始实现的分区虚拟化程序。尽管遵循与 Jailhouse 相同的架构但 Bao 不依赖于任何外部依赖除了执行低级平台管理的固件。另外由于机制的简单性它提供了对缓存着色的原生支持。Bao 最初针对 Armv8 架构也提供了对 RISC-V 架构的实验性支持。鉴于我们坚信安全不能仅依赖混淆而实现这是大多数行业参与者遵循的方法而且一再证明是无效的因此 Bao 将于2019年底开源。
2、 Bao Hypervisor
Bao源自普通话中的 “保护”意为“保护”是一个面向安全和安全性的轻量级裸金属bare-metal管理程序。专为混合关键性系统设计其重点强调隔离以实现故障隔离和实时行为。其实现仅包括一个最小、薄层特权软件利用 ISA 虚拟化支持来实现静态分区虚拟化程序架构图1资源在VM实例化时静态分区和分配使用两级转换静态分配内存仅支持IO的直通虚拟中断直接映射到物理中断实现虚拟到物理CPU的1对1映射无需调度程序。Hypervisor 还提供了一种基本的跨VM通信机制基于静态共享内存机制 和 以超级调用触发的异步通知形式的跨VM中断。除标准的平台管理固件外Bao没有任何外部依赖例如依赖特权虚拟机运行的不可信的庞大的单一内核的通用操作系统GPOS因此其可信计算基础TCB要小得多。 2.1、 平台支持
Bao目前支持Armv8架构。RISC-V 实验性支持也可用但由于它依赖于尚未批准的虚拟化扩展因此尚无可运行该虚拟化程序的芯片。因此 RISC-V 移植仅部署在 QEMU 模拟器上该模拟器实现了最新版本的草案规范在撰写本文时版本为0.4。因此在本文的剩余部分我们将仅关注Arm架构的实现。截至撰写本文时Bao已被移植到两个Armv8平台赛灵思的 ZCU102/4 开发板上的 Zynq-US 和 华为海思的 Hikey 960 上的 Kirin 960。到目前为止Bao已能够托管多个裸金属应用程序FreeRTOS 和 Erikav3 RTOSs以及纯净的 Linux 和 Android 。
除了简单的串行驱动程序以执行基本控制台输出外Bao不依赖于特定于平台的设备驱动程序只需一个最小的平台描述例如CPU数量、可用内存及其位置即可移植到新平台。因此Bao 依赖于供应商提供的固件和/或通用引导加载程序来执行基线硬件初始化、低级管理 以及 将 Hypervisor 和客户镜像加载到主存储器中。这显著减少了移植工作。
**在支持的基于Arm的平台上Bao依赖于标准Power State Coordination Interface (PSCI) 的实现来执行低级电源控制操作进一步避免了对平台相关驱动程序的需求。在基于Arm的设备上Arm Trusted Firmware (ATF)提供了此功能。**在这些平台上Linux 本身依赖于 PSCI 进行 CPU 热插拔。当这些客户调用 PSCI 服务时Bao仅充当调用参数的过滤器和验证器以保证虚拟机抽象和隔离性将实际操作延迟至ATF。尽管我们能够直接从 ATF 引导但我们也一直在使用众所周知的 U-boot 引导加载程序来加载 Hypervisor 和客户镜像。
2.2、 时空隔离
根据隔离的主要要求Bao 首先会设置每个核心的私有映射。通过使用递归页表映射技术它避免了对物理内存的完整连续映射否则这对于执行软件页表遍历将是必要的。这种方法通常在管理多个地址空间时不太适用并且通常会增加页表查找的 TLB 占用量。然而鉴于每个CPU仅管理单个地址空间并且页表在初始化时已完全设置对于我们的静态架构和设计理念来说并非绝对如此。尽管如此所有核心共享针对每个CPU区域的映射用于核间通信以及 Hypervisor 图像本身。此外只有承载相同虚拟机的核心才会映射其全局控制结构。这些设计决策遵循了最小特权原则其中每个核心及其中的特权级别只能至少直接访问绝对必需的内容。通过最小化可能被利用的读/写特性器件访问的可用数据这种方法提升了数据完整性和机密性。此外虚拟化程序代码页标记为只读并通过配置为不可执行来强制实施 X⊕W 策略确保虚拟化程序数据页的安全。
客户隔离本身当然从硬件虚拟化支持提供的逻辑地址空间隔离开始。为了最小化翻译开销、页表压力和 TLB 压力Bao 在可能的情况下使用超级页在Arm术语中称为块这也可能通过促进 推测取回 来提高客户性能。至于时间由于独占式CPU分配无需调度程序再加上由客户直接管理的每个CPU架构计时器的可用性使得实现了完全逻辑时间隔离。
尽管这种架构固有的强大分区性以及减少现有虚拟化开销所做的努力这还并不足以保证确定性执行并满足关键客户任务的截止期限。在共享的最后一级缓存LLCs和其他结构中的微架构争用仍然允许在客户分区之间发生干扰。因此考虑到其简单性Bao从一开始就实现了页着色机制实现 LLC 缓存分区。然而着色也存在几个缺点。首先它强制使用最精细的可用页大小排除了使用超级页的好处。其次它还对实际物理地址空间进行了分区导致内存浪费和碎片化。关于着色的另一个问题是由于 Bao 依赖引导加载程序 bootloader 来加载客户镜像这些镜像连续布置在内存中因此它需要对它们重新着色即将原始加载的图像中与 为特定VM分配的颜色相符的非颜色 兼容页面复制到相符合的页面中这将增加VM的启动时间。着色可以独立启用为每个VM选择每个颜色。
2.3、 IO 和 中断
Bao 以只允许传递方式的 IO 配置直接将外设分配给客户。**在支持的架构中特别是Arm架构所有IO都是内存映射的通过使用现有的 内存映射机制 和 虚拟化支持提供的两级转换可以免费 for free 实现这一点。**Hypervisor 不验证特定外设的独占分配这允许多个客户以非监督的方式共享它。
通用中断控制器GIC是Arm架构中的中断路由器和仲裁器。尽管它提供了一些中断虚拟化功能但绝大多数可用的硬件平台都采用了GICv2或GICv3它们不支持直接将中断传递给客户分区。所有中断都转发到 Hypervisor 后者必须使用有限的待处理寄存器在VM中重新注入中断。除了特权模式切换增加了不可避免的中断延迟外这显著增加了中断管理代码的复杂性特别是如果要模拟中断优先级等功能。Bao 的实现确实遵循了这条路线因为许多 RTOSs 使用中断优先级有时甚至作为任务调度机制。这个问题在最新版本的规范中得到了解决即GICv4它绕过 Hypervisor 直接向客户传递中断。此外有限的虚拟化支持要求必须使用 陷入Trap 和 模拟Emulate 来实现客户对中央分发器的访问。根据客户对分发器的访问频率和访问模式这可能会显著降低性能。截至目前Bao仅支持GICv2。
3、 评估
本节中我们介绍了Bao的初始评估。首先我们将重点关注代码大小和内存占用情况。然后我们评估启动时间、性能和中断延迟。我们将客户端的原生执行裸机与托管执行独立运行以及托管执行时的干扰情况互相干扰进行比较以评估运行多个客户端时可能产生的干扰。我们还在启用缓存分区的托管场景中进行重复测试独立运行 - 带缓存分区和干扰 - 带缓存分区以了解这种第一级微架构分区对目标分区的影响程度并帮助减轻干扰。
我们的测试平台是 Xilinx ZCU104搭载了一个四核 Cortex-A53 运行在 1.2 GHz 的 Zynq-US SoC每个核心有 32K 的 L1 数据和指令缓存并且有一个共享的统一 1MB 的 L2/LLC 缓存。我们将目标测试虚拟机在一个核心中执行而在添加干扰时我们在另外两个虚拟机中分别执行两个额外的裸金属应用程序每个应用程序不断地写入和读取一个大小为 512KiB 的数组步长等于缓存行大小64字节。在启用着色的情况下我们将 LLC 的一半512 KiB分配给运行基准测试的虚拟机四分之一256 KiB分别分配给每个干扰的裸金属应用程序。虚拟化程序代码和基准应用程序均使用 Arm GNU 工具链版本 8.2.1 进行编译并进行了 -O2 优化。
3.1、 代码大小和内存占用
Bao是一个完全从零开始的实现没有外部依赖。在这一节中我们评估了i代码复杂性使用源代码行数SLoC和ii内存占用通过查看最终二进制文件的大小然后分析运行时的内存消耗。
代码分为四个主要部分arch 和 platform 目录包含了特定于目标的功能而 core 和 lib 目录则包含了主要的 Hypervisor 逻辑和实用工具例如字符串操作、格式化打印代码。每个目录的总SLoC和最终二进制文件的大小列在表1中。 表1 显示对于目标平台实现了总共5.6 KSLoC。这个小的代码库反映了系统总体复杂度的低水平。**大部分代码是用C语言编写的尽管低级初始化和上下文保存/恢复异常入口和退出等功能必须用汇编语言实现。**我们还可以看到架构特定的代码贡献了总SLoC的大部分。最大的罪魁祸首是 GIC 虚拟化支持占据了几乎总体 Armv8 代码的1/3约750 SLoC。在核心功能中代码内存子系统包括物理页分配和页表管理包含了大部分复杂性约 540 SLoC。最终二进制文件的大小详细列在表1的最右侧。静态分配的内存总量约为59 KiB。请注意大部分 .bss 段的尺寸主要是由于根页表的静态分配。忽略它加载的最终二进制文件总尺寸约为43 KiB。
接下来我们评估运行时分配的内存。在启动时每个CPU分配了一个 28 KiB 的私有结构。这个结构包括私有 CPU 堆栈和页表以及用于 CPU 间通信的公共页。对于这个四核平台启动时总共分配了 112 KiB。在初始化过程中Bao 进一步分配了 4 页16 KiB用于基于对象池的内部最小分配机制。此外对于每个虚拟机虚拟化程序将分配固定的 40 KiB 用于虚拟机全局控制结构另外每个虚拟 CPU 分配 8 KiB。对于每个虚拟机最大的内存开销将是页表的数量这将首先取决于分配的内存大小和内存映射的外设其次取决于是否启用了缓存着色。表2 显示了不同分配内存大小时使用的页表数量。它突显了缓存着色机制对页表大小带来的巨大开销。在所有虚拟机初始化之后除了使用上述对象池进行 CPU 间消息分配的微小例外情况外不再进行内存分配。 3.2、 启动开销
在本节中我们评估了 Bao 在启动时间上的开销而不是系统整体的启动时间。因此在任何系统或虚拟机的启动阶段均未进行任何优化。在此平台上完整的启动流程包括几个特定于平台的启动阶段iBootRom 执行低级初始化并将第一阶段引导加载程序FSBL加载到芯片上的内存中然后ii将 ATF、Bao 和客户机映像加载到主存储器中。接下来iiiFSBL 跳转到 ATF然后iv将控制权交给了 Hypervisor。
在我们的测量中我们使用 Arm 的自由运行架构计时器该计时器在 ATF 的早期阶段启用。因此这些值仅是对平台总启动时间的近似值因为它们不考虑先前的引导阶段。我们考虑了两种情况一个小型虚拟机117 KiB 映像大小和 32 MiB 内存运行FreeRTOS以及一个大型虚拟机39 MiB 映像大小和 512 MiB 内存运行Linux。对于每个虚拟机我们考虑了本地执行裸机场景以及托管执行时着色关闭和启用的情况分别 solo 和solo-col。我们测量了i虚拟化程序初始化的时间即从虚拟化程序执行的第一条指令到它将控制权交给虚拟机的时刻和ii到虚拟机内的第一个应用程序开始的总启动时间。我们强调 Bao 不执行客户机映像加载这与其他嵌入式虚拟化程序的情况不同。为此它依赖于引导加载程序。因此映像加载开销仅反映在总时间中。 表3 显示了每种情况下 100 个样本的平均结果。在小型虚拟机的情况下虚拟化程序初始化开销很小solo 和 sol-col 场景分别为 6.5 和 9.2 毫秒。与裸机情景相比总启动时间增加了约130.5和160.6毫秒。在运行 Linux 客户机的大型虚拟机的情况下Bao 自身初始化和虚拟机的启动分别需要约 9.6 和 156.2 毫秒solo 和 solo-col 场景。与本地执行相比总启动时间增加了约 830.7毫秒和 1842.4毫秒着色分别关闭和启用。首先要强调的是着色启用时虚拟化程序初始化时间的大幅增加。这主要是因为 Bao 需要对引导加载程序提供的平坦映像进行着色在此过程中将映像的多个段复制到符合着色要求的页面中。对于大型客户机映像来说这一过程更为恶化。其次总启动时间的增加始终大于虚拟化程序初始化时间。我们认为这是在客户机初始化期间的虚拟化开销的结果例如 2级转换 和 GIC分发器的陷阱和模拟。
3.3、 性能开销和干扰
为了评估虚拟化性能开销和虚拟机间的干扰我们采用了广泛使用的 MiBench 嵌入式基准套件。MiBench 是一组包含 35 个基准测试的套件分为六个子集每个子集针对嵌入式市场的特定领域汽车和工业控制、消费类设备、办公自动化、网络、安全和电信。对于每个基准测试MiBench 提供了两个输入数据集小和大。我们的评估重点放在汽车子集上因为这是 Bao 所针对的主要应用领域之一。该子集包括三个内存密集型基准测试因此更容易受到缓存和内存争用引起的干扰qsort、susan corners 和 susan edges。 图2显示了对汽车 MiBench 子集进行 1000 次运行的结果。对于每个基准测试我们将结果表现为相对于裸机执行情况的性能规范化值因此更高的值反映了性能较差。为了进一步研究和了解基准测试的行为我们收集了 qsort 基准测试的 L2 缓存未命中率、数据 TLB 未命中率以及内存访问指令的停滞周期率的信息。表4 显示了每种情景下小和大 qsort 基准测试的结果。
分析图2可以在所有基准测试中观察到相同的趋势尽管程度有高有低。首先注意到托管执行导致性能略微下降。表4 中反映了这一点L2 缓存和数据 TLB 未命中率都略微增加这反过来解释了内存访问停滞率的增加。正如预期的那样这源于 2级地址转换的虚拟化开销。其次当启用颜色时性能开销进一步增加。表4 中的结果显示了所有指标已经显著增加。同样正如预期的那样这可以解释为只有一半的 L2 可用并且着色排除了超级页面的使用显著增加了 TLB 压力。在干扰情景中性能显著下降。表4 中的结果证实这是由于 L2 缓存未命中的激增所致。最后我们可以看到通过着色进行的缓存分区可以显著减少干扰。表4 显示着色可以将 L2 缓存未命中率完全降至 solo colored 情景的水平。然而回顾图2我们可以看到这种削减并未在观察到的性能下降中体现出来在 interf-col 情景中性能下降仍然高于 solo-col 情景。这可以通过从 LLC例如写回缓冲区、MSHR、互连、内存控制器引入的仍未解决的争用来解释反映在内存停滞周期率的差异上。正如预期的那样由于 basicmath 和 bitcount 的内存需求要低得多它们受到的着色和干扰的影响明显较小。
图2 中另一个可见的趋势是性能下降在小型数据集变化的基准测试中总是更为明显。当比较小型和大型输入数据集的变体时我们可以看到尽管表4 中 L2 缓存未命中率的增加相似但小型变体经历了更大的性能下降。我们认为这可能是因为对于小型输入数据集基准测试由于其总执行时间更短缓存未命中的惩罚会更严重。表4 中观察到的内存访问停滞周期率支持了这一观点在小型输入数据集情况下它导致了更高的百分比增加。 3.4、 中断延迟
为了测量中断延迟并最小化与虚拟化无关的开销我们设计了一个极简的裸机基准测试应用程序。该应用程序连续设置了体系结构计时器每 10ms 触发一次中断。由于知道中断触发的时刻我们将延迟定义为预期挂钟时间与实际开始处理中断的时刻之间的差值。计时器具有 10 ns 的分辨率。对于每种情景我们获取了 1000 个样本的结果总结如表5 所示。 当将原生执行与独立托管执行进行比较时我们看到平均延迟和标准偏差显著增加分别约为 430ns 和 40ns 最坏情况延迟增加了 1680ns 。这反映了已经预期到的 GIC 虚拟化开销因为陷入和模式切换的成本以及中断管理和重新注入。同时可见着色本身并没有显著影响平均中断延迟但略微增加了最坏情况的延迟。表5 中的结果也证实了缓存和内存争用对中断延迟的不利影响特别是在最坏情况下。平均延迟增加了约 12ns 标准偏差增加了约 41ns最坏情况延迟增加了 1160ns。启用着色在平均延迟上没有显著的好处实际上增加了标准偏差和最坏情况的延迟。我们认为这是因为在这种情况下相关的干扰实际上不是在虚拟机之间而是在干扰的客户和未着色的 Hypervisor 之间。
4、 相关工作
虚拟化技术始于20世纪70年代。如今虚拟化是一项成熟的技术有着丰富的 Hypervisor 解决方案主要应用于各种场景从服务器、桌面到移动设备甚至到高端和低端嵌入式系统。
Xen 和 KVM 是代表性的开源 Hypervisor涵盖了广泛的应用范围。Xen 是一种裸机Type-1Hypervisor依赖于一个特权 VM称为 Dom0来管理非特权VMDomUs并与外设交互。KVM 采用不同的设计理念它被设计为一个 Hosted Hypervisor并且在 Linux 的主干版本中集成从 2.6.20 版本开始。虽然最初是为桌面和服务器应用开发的但这两种 Hypervisor 已经在嵌入式领域找到了自己的位置。Xen 在 Arm 架构上的实现Xen on Arm是首个面向 Arm 平台的 Xen 实现而 RT-Xen 则通过实时调度框架进行了扩展。而 KVM/ARM 则提出了分离模式虚拟化的概念并推动了 Arm 平台的硬件虚拟化规范。
另一方面为了满足嵌入式实时应用的严格时序需求另一类系统提出了对广泛使用的商业 RTOS 进行扩展加入虚拟化功能。Green Hills INTEGRITY Multivisor、SysGo PikeOS 和 OKL4 MicroVisor 是利用已开发和认证的 RTOS 基础设施的优秀示例以提供实施虚拟化能力作为服务或模块。还有一类系统利用面向安全的技术例如 Arm TrustZone 进行虚拟化。基于 TrustZone 的 Hypervisor比如 SafeG 和 LTZVisor 通常是双操作系统解决方案允许两个不同的执行环境即 RTOS 和 GPOS进行合并。尽管这两种设计理念都致力于降低性能开销和最小化中断延迟但它们通常在支持多个 VM 和多核配置的扩展性方面存在一些限制。
像 Xtratum、XVisor、Hellfire/prpl-Hypervisor、ACRN 和 Minos 这样的小型 Type-1 嵌入式 Hypervisor在全功能 Hypervisor 和虚拟化增强的 RTOS 之间提供了很好的折衷方案。Xtratum 是针对 LEON 处理器设计的用于安全关键航空航天应用的 Hypervisor如今它也适用于 x86、PowerPC 和 Armv7 指令集。Hellfire/prplHypervisor 是专门为针对MIPS架构的实时嵌入式系统设计的支持虚拟化模块。XVisor 是专为在 Arm 平台上引入嵌入式虚拟化而设计的工具吸引了很多学术界和业余爱好者。英特尔研究人员开发了 ACRN 这是一个面向物联网领域的轻量级 Hypervisor目前针对 x86 平台。Minos 是一个针对移动和嵌入式应用的新兴解决方案。与这些 Hypervisor 类似Bao 也是一个针对 Arm 和 RISC-V 处理器的 Type-1 Hypervisor并开放未来支持MIPS或其他嵌入式平台然而它通过遵循静态分区架构使得 TCB 进一步减少并提高了实时性能。
Siemens 的 Jailhouse 是采用了 Bao 所采用的静态分区架构的先驱。Jailhouse 利用 Linux 内核启动系统并使用内核模块在已运行的 Linux 下安装 Hypervisor。然后它依赖于这个 root cell 来管理其他 VM。由于静态分区在汽车等嵌入式领域的优势得到了证实其他 Hypervisor 也在努力支持它。Xen 最近推出了 Dom0-less 执行允许DomUs在没有Dom0的情况下启动和执行这也消除了对Linux的依赖。我们坚信 Bao 将能够通过提供同样的静态分区优势拥有更小的 TCB可信计算基以及实现清晰的安全功能从而与 Xen 的 Dom0-less 区别开来。
最近Google 开源了 Hafnium一个以安全为重点的 Type-1 Hypervisor。它旨在在一组安全域之间提供内存隔离以更好地将不受信任的代码与安全关键代码隔离开来其中每个安全域都是一个VM。
5、 On the Road
Bao 的开发仍处于萌芽阶段。截至目前我们正在扩展对 Arm 架构的支持包括 SMMUArm 的 IOMMU和最新的 GIC 版本v3 和 v4。我们还在将系统移植到一系列不同的平台包括 NVIDIA 的 Jetson TX2 和 NXP 的 i.MX 8。此外考虑到代码库规模较小我们计划进行全面的重构以符合 MISRA C 编码准则。
Bao 从一开始就实现了缓存着色作为微架构分区和隔离的第一线。我们的目标是实现其他最新的分区机制例如内存限流并对 Hypervisor 镜像本身进行着色因为我们已经验证了 VM 之间或 VM 与 Hypervisor 之间仍然存在争用问题。然而我们认为这些问题应该由专用硬件机制支持以避免增加代码复杂性和大小并尽量减少开销。事实上Arm 在 Armv8.4 上提出了 Memory System Resource Partitioning and MonitoringMPAM 扩展。MPAM 提供了对共享缓存、互连和内存带宽的硬件支持。然而迄今为止尚无可用的支持这些扩展的硬件。我们计划使用 Arm Foundation Platform 模型实现对 MPAM 的支持以便在真实硬件上进行测试一旦这些硬件可用即可进行测试。
最后由于 Bao 也是一个面向安全的 Hypervisor受信执行环境TEE的支持也在路线图上。通常Arm TEE 是基于 TrustZone 技术的这是一组安全硬件扩展将平台分为安全和普通世界。TEE 内核和应用运行在安全方面而其他所有内容包括 Hypervisor在普通世界执行。目前TrustZone 不支持多个隔离的 TEE。几种安全世界虚拟化方法已经提出最近Arm 在 Armv8.4 上添加了对安全世界 Hypervisor 的支持。然而基于 TrustZone 的 TEE 的双世界方法已被证明基本上存在缺陷。此外我们认为运行额外的安全 Hypervisor 会不必要地增加复杂性并且安全世界应仅用于封装绝对安全原语例如安全启动、证明、认证、密钥管理。Bao 的方法将考虑到这一点并利用已有的虚拟化机制无需额外的调度逻辑允许在普通世界的单个硬件分区中运行多个VM。TEE 将部署在辅助 VM 上并仅在主要客户端请求时执行。此方法的另一个优点是它在不同架构之间具有可移植性和可扩展性而不是特定于 Arm。
6、 总结
在本文中我们介绍了 Bao Hypervisor这是一种对现有嵌入式 Hypervisor 的轻量级替代方案是静态分区架构的最小、独立和清晰实现。尽管开发仍处于初级阶段初步评估显示其仅带来了极小的虚拟化开销。我们概述了 Bao 的开发路线图其中包括扩展的平台支持和每个分区的 TEE 支持。Bao 将于 2019年 底开源希望引起学术界和行业界对虚拟机隔离和安全性挑战的关注。
