演讲嘉宾 | 杜 东
回顾整理 | 廖 涛
排版校对 | 李萍萍
嘉宾简介
杜东，上海交通大学助理研究员。中国计算机学会CCF会员，ACM会员。研究兴趣为操作系统与体系结构、服务器无感知（Serverless）计算、系统安全。在包括ASPLOS、ISCA、OSDI、SOSP、ACM SoCC、TOCS等国际著名会议和期刊发表/录用多篇学术论文。
内容来源
第一届开放原子开源基金会OpenHarmony技术峰会——安全及机密计算分论坛
视频回顾
视频链接：
峰会回顾第13期 | 开源机密计算平台：蓬莱-OpenHarmony（杜东）_哔哩哔哩_bilibili
正文内容
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的安全底座。
