華為鴻蒙系統HarmonyOS學習之十：鴻蒙HarmonyOS微核心技術

 

一、前言

       把作業系統中更多的成分和功能放到更高的層次（即使用者模式）中去執行，而留下一個儘量小的核心，用它來完成作業系統最基本的核心功能，稱這種技術為微核心技術。

在微核心中通常提供了以下的功能：

1. 程式/執行緒管理
2. 低階儲存器管理
3. 中斷和陷入處理

微核心具有以下的特點：

1. 足夠小的核心
2. 基於客戶/伺服器模式
3. 應用機制與策略分離原理
4. 採用物件導向技術

機制與策略的概念

1. 機制：實現某一功能的具體執行機構（what）
2. 策略：在機制的基礎上藉助於某些引數和演算法實現該功能的優化（how）

微核心的優缺點

優點：

1. 系統服務模組化，可移植性高；

2. 核心安全性提高（模組內部的 Bug 不影響核心穩定，將黑客利用軟體漏洞造成的破壞限制在單個模組內部）；

3. 可以多套系統服務共存，相當於同時執行多種作業系統；

4. 穩定統一的介面（可以獨立維護私有驅動以及服務，不需要跟核心原始碼繫結）；

5. 在商業上，微核心可以避免程式碼受到一些開源協議的影響，比如 GPL 協議；

6. 核心精簡，可以進行形式化驗證，利用數學證明核心的安全性；

7. 數學可證明的實時性；

8. 非常適合多處理器系統設計，在多處理器核心計算機上，互相依賴的系統服務可以同時執行；

缺點

1. 通過程式通訊的方式交換資料或者呼叫系統服務，而不是使用系統呼叫，造成額外的作業系統開銷；

2. 使用一些頻繁使用的系統服務時，比如網路收發資料，造成的程式上下文切換對作業系統來說也是一個負擔；

3. 由於系統服務高度模組化，系統服務之間存在大量的記憶體複製；

4. 對互相之間存在複雜呼叫關係的系統服務，難以設計通訊介面；

5. 系統服務與核心在地址空間上分離，造成程式碼區域性性差，降低了 cache 命中率。

二、微核心的發展歷史

微核心這個概念從提出開始到現在就在一直處於不斷地發展、完善進步之中，到目前為止可以分為三個歷史時期，也可以稱為三代。

第一代微核心：從無到有

     第一代微核心的主要代表是 Mach，由美國卡耐基梅隆大學的 Avie Tevanian 和 Richard Rashid 主導開發的。當時正是UNIX 發展正如日中天時期，因此Mach不可避免的受到UNIX的影響，最起碼相容unix是最起碼的考量，但是與 UNIX 不同的是 Mach 使用微核心架構。Mach 以 IPC 是作為所有系統服務與核心交換資料的基礎機制，充分運用 IPC、虛擬記憶體、多程式等特性將冗餘的系統服務移出核心作為程式執行。

     1986年，Mach 釋出了第2版，但此時 Mach 核心並不提供完全的系統服務，該本的核心包含了大量 4.3 版本的 BSD 系統（UNIX的一個分支）程式碼提供系統服務，並且 BSD 系統服務執行在核心狀態，這導致 Mach 核心的程式碼體積甚至大於常規 UNIX 核心。這兩個版本達成了如下的目標：

• 驗證了微核心的可行性；
• 在多處理器計算機上進行移植驗證了微核心在多處理器計算機上的執行；
• 最後為了提高 IPC 的效率，Mach 使用共享記憶體機制來完成 IPC。

         Mach 的共享記憶體機制是在虛擬記憶體技術的支援下實現的，只有需要對記憶體進行寫入時才進行復制。這麼一處理比每次都複製一遍記憶體節省了記憶體使用同時又加快了 IPC 機制的處理時間，這個改進稱為寫時複製，並且在如今的通用作業系統如 Linux 中常常用到。經過測試，Mach 2.5的效率最多比 UNIX 少 25%，但是考慮到 Mach 帶來的可靠性、可擴充性、安全性，這個效率損失尚可以接受。此時 Mach 核心還不算完全的微核心。而考慮到微核心可以更高效地利用多處理器計算機的處理器核心資源，寄希望Mach 把系統服務都搬到核心之外後可以把執行效率損失降下來。開放軟體基金會（Open Software Foundation，OSF）宣佈下一代系統 OSF/1 將基於 Mach 的核心， 眾多公司開始採用這個核心：如NeXTSTEP 使用 Mach2.5（未與蘋果合併之前）；IBM 利用 Mach 構建 Workplace OS；蘋果公司基於 Mach2.5 打造其作業系統核心 XNU。

      Mach 3.0 於 1990 年釋出，由於在系統服務之間完全使用 IPC 通訊，而不是向單核心那樣直接進行函式呼叫，即便是多處理器機器上執行也效能損失慘重，Mach 3.0 最多比 UNIX 損失 67% 執行效率，這導致 Mach 3.0 以及其所代表的第一代微核心設計被看衰。此後斷斷續續有在 Mach 的基礎上對效能進行提升的嘗試，但是均不太理想，至此 Mach 成為了微核心第一代先驅者。

第二代微核心：解決效能問題

      第二代微核心的主要代表是 L3 和 L4，以及 QNX 系統使用的 Neutrino 核心。前面第一代的微核心 Mach 由於效率問題原因失敗了，但是微核心的理念並沒有被放棄，Jochen Liedtke 認為 Mach 的 IPC 效率低下的原因就是因為 IPC 部分不夠精簡，於是有了L3 和 L4 微核心，對 IPC 部分進行了很徹底的精簡優化：

• 核心的 IPC 機制只是單純地傳遞資訊，諸如安全許可權檢查這類的程式碼都省略掉，省略掉的功能全部由使用者程式自己處理。如此一來 IP C功能部分的程式碼執行時間大大縮短；
•  IPC 不使用記憶體傳遞訊息，而使用暫存器傳遞訊息，同時限制 IPC 每次傳遞的資訊長度，這樣省去了對記憶體的訪問時間。L4 微核心的 IPC 速度經過測試要比 Mach 快 20 倍，這個令人驚訝的優化效果吸引了眾多的目光，使微核心的研究重新火熱起來。後面 L4 核心又發展出了很多相關係統，比如 Pistachio、L4/MIPS 與 Fiasco 等等，這些核心組成了 L4 的大家族。

 

         第二代微核心的代表除了有 L4 核心，也還有其他微核心比如 Exokernel、Rambler 等，但做的比較成功的是：黑莓公司旗下的 QNX 系統所使用的 Neutrino 核心（QNX，1980年誕生，最初以 QUICK UNIX 為名，後改為 QNX；2004 年 QNX 被 Harman 國際收購；2010 年 Harman 國際下被黑莓收購，QNX 成為黑莓旗下的資產），QNX 主要為高可靠領域提供解決方案，比如交通、能源、醫療、航天航空等。

 

第三代微核心：主要重視安全問題等

        在前面兩代的微核心的基礎上，第三代微核心蓬勃發展，許許多多微核心都被開發出來，主要代表有：seL4、Fiasco.OC、NOVA 等。

        本來第一代微核心的設計隔離了使核心安全性降低的系統服務，讓系統服務漏洞不會影響核心，進而提高了核心安全性，可以說是關上了破壞系統的門， 但是第二代系統卻又給攻擊者開了個窗戶。

       由於第二代微核心在核心中省去了關於安全性檢查等步驟，把所有關於安全檢查功能的實現都交給系統服務自己去實現，這導致系統服務的通訊介面直接暴露給使用者態，任何程式都可能無限制地請求系統服務，系統服務不得不花費額外的代價來區分請求是否合法，容易造成拒絕服務攻擊。

        比如正常的檔案服務應該是從虛擬檔案系統服務->檔案系統服務->磁碟驅動服務這個流程來完成的，但是如果攻擊者如果繞過虛擬檔案系統服務，直接無限制地請求攻擊者本身沒有許可權訪問的檔案系統服務，使檔案系統服務長期處於滿載狀態，讓其他程式無法通過正常的虛擬檔案系統得到檔案系統服務。為了增強安全性，且不過分影響效能，人們開始研發第三代微核心。

          seL4 是在第二代核心 L4 的基礎上發展而來的。seL4 不僅僅繼承了 L4 核心家族的高效能特性，還具備基於端點（enndpoint）的 IPC 機制。

          這種 IPC 機制最大的特點是使用了能力空間的概念，程式在使用 IPC 請求系統服務時必須具備相對應的能力，程式持有不可偽造的令牌來表示擁有請求某種服務的能力。令牌可以被複制，可以被轉移，還可以通過 IPC 進行傳輸。令牌其實是一個指向存在於核心空間核心物件的指標，所以普通程式並不能修改自身以及其他程式的許可權分配，但是核心可以對令牌指定的許可權進行控制，從而保證了使用者態不能繞過能力空間這個機制對系統服務造成濫用。

     seL4 還是第一個完全通過形式化驗證的核心，通俗說形式化驗證就是在數學軟體的幫助下使用數學語言自動化地推導檢查系統的每一個執行狀態。seL4 形式化驗證相關論文。

三、微核心與單核心的對比

單核心的架構圖

微核心架構圖

            形象一點說單核心就是作業系統是個大管家，幾乎包辦一切，使用者應用程式的需求直接向核心提出就行；微核心更像一個代理人，幾乎所有的驅動、檔案系統全部執行在與使用者應用程式平級的使用者模式下。

        如果把作業系統看成一家公司，而單核心的特點是使用者請求直達核心，核心統一安排執行，這代表此公司使用扁平化的管理架構，而微核心的作業系統中則需要設立很多如驅動，檔案系統等部門，這顯示公司使用制度化、等級化的管理架構。也就是說，如果單核心代表的是層次簡單的扁平化管理風格，微核心則代表多部門的制度化管理風格。

       執行效率單核心更優：形象一點，就類似去政府部門跑公章的經歷，很多時間、精力都浪費在了部門（程式）之間的上下文切換(上文已經釋義)中了，微核心在效率方面肯定是處於劣勢的，所以目前的主流作業系統如Linux和Windows本質上使用的都是單核心，當然有人會說Windows使用的是混合核心，不過這種混合核心也是以效率優先的扁平化架構，本質上還是單核心。

單核心vs微核心，誰更安全？：單核心採用扁平化管理，扁平化雖然能有比較高的效率，但是難免會在身份鑑別、資料傳遞的過程中出現紕漏，從而給入侵者可乘之機。微核心將其核心抽象成一個有限狀態機，進而證明在狀態遷移與躍遷的過程中都不會發生會被惡意利用的漏洞，從而保證整個體系的安全。當然這個安全也有前提：

• 不能有內鬼：即生成核心的編譯器、連結器與操作執行的硬體環境如DMA等裝置不能被提前惡意植入後門。
• 不能有密碼洩露：形式化驗證只能保證制度體系本身不出問題，如果使用者將自身密碼洩露那系統是無法防範的。

我們知道單核心的作業系統尤其是Windows，經常會暴出安全漏洞，使用者在沒有洩露密碼且沒使用問題硬體的情況下，還是會遭到被黑客入侵。所以在安全性對比上微核心可謂優勢明顯。

單核心vs微核心，誰實時性強？：效率更優的單核心在實時性方面的表現其實不如微核心。那些對於實時性要求極高的軍用作業系統（如vxWorks等）使用的都是微核心架構。

單核心vs微核心 誰更適合多核處理器？：單核心會在CPU核心間不斷進行上下文切換，而微核心則不斷在程式間進行上下文切換。微核心的迴歸驗證了微核心與多處理器的硬體平臺配合會更好

四、鴻蒙的微核心的微核心技術

•   微核心架構包含兩類元件：核心系統和外掛系統。核心系統的功能穩定，很少變更，其只擁有能使應用執行的最小功能邏輯，這些通用邏輯(例如外掛模組的註冊、載入、解除安裝，以及外掛模組之間的相互通訊等)不涉及任何特定業務；外掛系統則具備良好的擴充套件性，其負責實現特定的業務邏輯，可根據特定業務需求而變更。
      顯而易見，微核心架構本質上其實是將一個軟體系統中的變化部分封裝在外掛中，從而實現不同業務之間的隔離性，達到系統快速靈活擴充套件的目的，同時所有特定業務相關邏輯的變更不會影響整體系統的穩定性。

• 設計要點
  微核心架構設計有以下三個關鍵點：外掛管理、外掛連結和外掛通訊。

1. 外掛管理
       核心系統需要知道當前系統中共有多少個外掛，哪些外掛處於可用狀態，什麼時候載入一個外掛，如何載入一個外掛等。
       實現上述功能的一個常用機制是外掛登錄檔：核心系統提供一個服務來響應外掛的註冊請求，最終將當前系統的所有外掛資訊（外掛標識，類別，啟動方式等）儲存起來。儲存方式可以選擇配置檔案儲存或者資料表儲存等。
   
2. 外掛連結
       外掛連結制定了一個外掛與核心系統的通訊方式，也就是連結規範，故任何一個可用外掛都務必遵從核心系統中該類別外掛所制定的連結規範。
       常見的連結規範有OSGI（Eclipse），訊息佇列，依賴注入（Spring），RPC等。
3. 外掛通訊
       外掛模組的設計是為了達到低耦合目的，也符合這一原則。但一個業務請求往往需要幾個外掛模組共同協作來實現，這就需要外掛之間可以實現相互通訊。外掛之間的通訊則需要通過中央處理器（核心系統）來作為橋樑，故核心系統除去提供上文提及的登錄檔機制之外，還需要提供類似作業系統匯流排之類的通訊機制。

五、業界其他的微核心系統：Fuchsia、Minix

       Fuchsia 是 Google 開發的一款全新作業系統，試圖覆蓋手機、平板甚至筆記本等一系列領域。Google 為該系統配備了 Vulkan 圖形介面、3D 桌面渲染 Scenic、Flutter 應用開發框架，還有一個稱為 zircon 的微核心。

       zircon 核心是從高通平臺的一個 Bootloader 專案：Little Kernel發展而來。zircon核心屬於微核心設計，只提供 IPC、程式管理、地址空間管理功能。zircon 區別於以程式或者以檔案為核心的設計，zircon 是以記憶體為核心來設計的，記憶體在 zircon 中是以物件的方式存在，可以通過 channel 通訊機制傳遞虛擬記憶體物件（Virtual memory object）的控制程式碼，程式拿到控制程式碼後可以把這塊記憶體對映到自己的空間。

      Minix 系統則由荷蘭阿姆斯特丹的 Vrije 大學的 Andrew S.Tanenbaum 教授所開發。該系統最大的特點是可以故障隔離，自動重啟失敗的服務。Minix 使用分層設計，最底層的微核心提供中斷處理、程式管理、程式通訊等服務，這一層執行在核心態；中間層提供輪迴服務（Reincarnation Server）、檔案服務、程式管理、X 圖形服務以及驅動等，這一層執行在使用者態，最上層為使用者程式。其中輪迴服務負責在中間層的服務出現崩潰時重啟這些服務，從而保證服務的自我修復。Minix 由於其自我修復特性被英特爾管理引擎（ME）所選用，該管理引擎主要負責管理英特爾晶片的內部模組。