开源机密计算平台：蓬莱 -OpenHarmony

演讲嘉宾 | 杜   东

回顾整理 | 廖   涛

排版校对 | 李萍萍

嘉宾简介

杜东，上海交通大学助理研究员。中国计算机学会 CCF 会员，ACM 会员。研究兴趣为操作系统与体系结构、服务器无感知（Serverless）计算、系统安全。在包括 ASPLOS、ISCA、OSDI、SOSP、ACM SoCC、TOCS 等国际著名会议和期刊发表/录用多篇学术论文。

内容来源

第一届开放原子开源基金会 OpenHarmony 技术峰会——安全及机密计算分论坛

视频回顾

正 文 内 容

OpenHarmony 赋能万物互联，存在覆盖从端到云的安全能力需求。蓬莱-OpenHarmony 是一个开源机密计算平台，提供了面向 OpenHarmony 的可信执行环境，赋能 OpenHarmony 安全能力。那么，蓬莱-OpenHarmony 主要做了哪些安全增强方面的工作，有哪些关键技术呢？上海交通大学助理研究员、中国计算机学会 CCF 会员、ACM 会员杜东在第一届 OpenHarmony 技术峰会上给大家带来了几点分享。

01►万物互联计算的安全挑战

当进入到万物互联的新场景后，存在哪些安全风险和挑战，又有哪些解决方案呢？

依靠软件本身提供系统安全能力是一种方案。但是，依赖形式化验证、类型安全语言等技术目前来加强系统安全，目前看来是较为困难的。在万物互联的场景中，开发者的背景和能力多样性倍增，各自所依靠开发软件本身处理安全风险的能力不尽相同。就算能够实现，也可能需要更多的辅助工具来配合开发者完成。

通过软硬件配合，依赖于硬件提供的安全特性来加固系统，为其提供可信执行环境（TEE）是另一种可行的系统安全加固方案。可信执行环境能够有效增强边缘设备的安全能力，例如内存隔离、I/O 隔离等。依赖该方案进行安全加固的代表系统有 Intel SGX、ARM TrustZone 和 RISC-V 蓬莱或 Keystone 等。目前，已经发布了多个安全特性扩展和完善的可执行环境方案，为什么还要定制化设计一个蓬莱-OpenHarmony 呢？因为 OpenHarmony 所面临的万物互联场景是有不一样的挑战和风险，主要有以下 3 个方面：

第一，万物互联会导致需要面临复杂的硬件环境。在异构的硬件环境下，通过一套系统把 OpenHarmony 的安全特性和需求支撑起来，是非常复杂的一件事。例如，端侧可能存在非常小型的低配设备，没有页表和内存隔离，但是 TEE 很难跑在这种配置下；又例如，在较高配的手机场景，怎么能够让小型的、没有很多基础安全能力的环境和有安全能力的环境进行协同，也是一个较大的挑战。

第二，软件栈存在差异。面向云场景，软件主要基于 Linux 内核和虚拟机监控器等，必要时可引入如安全 OS 等组件；而面向边缘及 IoT，软件栈较为简单，可能基于 RTOS（如 OpenHarmony 小型内核）等构建整个软件栈。因此，如何使得二者进行协同，是软件异构所带来的问题。

第三，操作系统国产化问题。例如 OpenHarmony 目前在系统安全方面已经有所成果，如何保证它的安全能力自主可控呢？这也是需要思考的一个风险和挑战。

蓬莱-OpenHarmony 能够有效解决上述问题，下图是蓬莱-OpenHarmony 的 logo。讨论一个有趣的话题：为什么新的系统命名为蓬莱？蓬莱是中国古代神话里面的一座仙岛，其被一片黑色的冥河所包围。我们希望提供一个可信执行环境，它是和外界隔离的，里面的东西不能出来，外面的东西也不能进去。一方面能够保证内部机密数据的安全，另一方面也能够避免内部不安全因素因其特殊的地位而对外部造成损害。

02►蓬莱-OpenHarmony

在蓬莱-OpenHarmony 的项目中，开发了蓬莱可信执行环境并提供了通用的解决方案。目前主要做的四项工作有：（1）提出面向 OpenHarmony 的通用 TEE 架构和接口，明确架构和接口的定义，保证后续所有的 TEE 都能够满足某一个抽象或某一个核心接口而被纳入 OpenHarmony 体系中；（2）基于 RISC-V v1.10 的指令集，开发了蓬莱安全硬件扩展；（3）开发固件层(M-mode) Monitor 和 TEE SDK 的软件层；（4）提供含 MMU 平台和无 MMU 平台的两套系统支持。

2.1►►RISC-V 生态

在 RISC-V 生态中，开发者可以自身需求定制化设计硬件而无需担心版权风险，如果硬件的特性足够好，还可以将其合入到 RISC-V 的官方指令集中。截至 2022 年，RISC-V 处理器出货量达到 100 亿，Semico Research 预测到 2025 年，RISC-V 处理器出货量将达到 800 亿，构建了强大的影响力和生态。

RISC-V 设备的急剧增加，逐步形成了万物互联的端边场景，RISC-V 的 CEO Calista Redmond 预测，到 2030 年将有 500 亿联网和物联网设备需要安全和定制处理器加持，需要有足够多的安全特性以保证身边的设备能够满足计算和处理器的需求。

2.2►►面向 OpenHarmony 的通用 TEE 架构和接口

面向 OpenHarmony 的通用 TEE 架构和接口当前还处于草案的状态。如下图所示，架构本身和 RISC-V 无关，并未涉及到具体的架构和特性。我们认为，未来 OpenHarmony 的通用 TEE 架构和接口可能包含 4 层：最底层是所需要的硬件特性，其上层为安全固件；可信执行环境操作系统在安全固件的上层；最上层即用户应用层。

2.3►►蓬莱-OpenHarmony：RISC-V 指令集下的 TEE 系统架构

蓬莱-OpenHarmony 的整体架构如下图所示。蓬莱-OpenHarmony 基于上述定义的 OpenHarmony TEE 参考架构；在硬件上进行了创新，面向万物互联异构的场景，提出了细粒度的轻量隔离，其安全特性是可配置和可选的；在软件上也进行了创新，面向多元隔离的需求，支持安全 OS 和轻量安全应用；此外，蓬莱-OpenHarmony 也支持 OpenHarmony 标准、小型、轻量等配置。

2.4►►硬件异构应对案例

在硬件异构的场景中，如何实现内存隔离呢？RISC-V 将整个软硬件分为硬件层、机器态、特权态以及用户态共 4 层。其中，硬件层 RISC-V 支持不同的特性及扩展；机器态即固件层，拥有比特权态更高的权限，通常负责加载操作系统或者实现安全特性；特权态运行操作系统内核，支持 MMU 和 no-MMU 平台；用户态则运行各类应用程序。可信执行环境的基础能力，要求内核和应用之间要内存隔离，云边场景可以通过内存管理模块 (MMU)/页表实现，但 IoT 和边缘 RISC-V 设备可能没有 MMU，内核和应用之间缺乏隔离性。

怎么解决呢？如下图所示为一个临时解决方案，即将内核运行在机器态，机器态中有一套硬件机制 PMP，可以通过 PMP 控制来隔离内核和用户态。例如，Linux 在没有 MMU 的时候，通过 RISC-V 机器态的 PMP 隔离机制实现粗粒度隔离。但随之而来出现一个问题，机器态固件和操作系统之间会存在机器态争抢，其问题根本是边缘设备硬件情况不同所导致，对于小型硬件经常存在这样的问题和风险。

在蓬莱-OpenHarmony 中，提出了新的 RISC-V 硬件扩展：sPMP。sPMP 是轻量级的内存隔离机制，存在硬件资源开销低、访存性能好的优势。有 sPMP 和没有 sPMP 的区别在什么地方呢？当没有 sPMP 时，机器态是有内存隔离的，但是用户态和 OS 态之间没有任何隔离，很难在上面运行多个 APP；有 sPMP 后，操作系统依赖 sPMP 寄存器就可以实现隔离，补齐了机制缺陷。

2.5►►软件异构应对方案

在软件异构场景中，隔离域依赖于安全硬件的物理内存隔离机制，如 RISC-V 段隔离机制。其问题是隔离域与硬件强相关，比如 PMP，最终的总体隔离数量与 PMP 个数是呈正相关。段隔离机制本身是有限的 (不超过 16 个)，4 组 PMP 寄存器现在最多只能划分出 4 个域，如图所示。

那么可信执行环境如何提供可扩展的隔离域呢？在云场景中，可以利用软件隔离出更多隔离域，但在边端由于内存资源不足并不适用。针对此问题，蓬莱-OpenHarmony 提供了滑动窗口的隔离域设计，使一组 PMP (逻辑上) 保护多个隔离域，在上下文切换时滑动实际的保护范围。如图所示，当隔离域-1 被执行时，PMP-2 能够将隔离域收缩至隔离域-1 的范围；反之，当隔离域-2 被执行时，PMP-2 也能够将隔离域收缩至隔离域-2 的范围。如此一来，能够保证每一个隔离域执行时，其内存保护的范围是准确的。

03►总结

总的来说，蓬莱-OpenHarmony 项目为 OpenHarmony 在 RISC-V 架构下提供了安全基石，支持 OpenHarmony 面向万物互联的多场景安全需求。欢迎大家持续关注蓬莱-OpenHarmony 项目，我们也期待更多的开发者能够加入其中，共同赋能 OpenHarmony 的安全底座。