演講嘉賓 | 杜 東

回顧整理 | 廖 濤

排版校對 | 李萍萍

嘉賓簡介

杜東，上海交通大學助理研究員。中國計算機學會CCF會員，ACM會員。研究興趣為操作系統與體系結構、服務器無感知（Serverless）計算、系統安全。在包括ASPLOS、ISCA、OSDI、SOSP、ACM SoCC、TOCS等國際著名會議和期刊發表/錄用多篇學術論文。

內容來源

第一屆開放原子開源基金會OpenHarmony技術峰會——安全及機密計算分論壇

正 文 內 容

OpenHarmony賦能萬物互聯，存在覆蓋從端到云的安全能力需求。蓬萊-OpenHarmony是一個開源機密計算平臺，提供了面向OpenHarmony的可信執行環境，賦能OpenHarmony安全能力。那么，蓬萊-OpenHarmony主要做了哪些安全增強方面的工作，有哪些關鍵技術呢？上海交通大學助理研究員、中國計算機學會CCF會員、ACM會員杜東在第一屆OpenHarmony技術峰會上給大家帶來了幾點分享。

01?

萬物互聯計算的安全挑戰

當進入到萬物互聯的新場景后，存在哪些安全風險和挑戰，又有哪些解決方案呢？

依靠軟件本身提供系統安全能力是一種方案。但是，依賴形式化驗證、類型安全語言等技術目前來加強系統安全，目前看來是較為困難的。在萬物互聯的場景中，開發者的背景和能力多樣性倍增，各自所依靠開發軟件本身處理安全風險的能力不盡相同。就算能夠實現，也可能需要更多的輔助工具來配合開發者完成。

通過軟硬件配合，依賴于硬件提供的安全特性來加固系統，為其提供可信執行環境（TEE）是另一種可行的系統安全加固方案?？尚艌绦协h境能夠有效增強邊緣設備的安全能力，例如內存隔離、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平臺；用戶態則運行各類應用程序?？尚艌绦协h境的基礎能力，要求內核和應用之間要內存隔離，云邊場景可以通過內存管理模塊 (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的安全底座。

E N D

點擊下方閱讀原文獲取演講PPT。

關注我們，獲取更多精彩。