這是四部分系列文章的第二部分，介紹了獨特的產品 MPU-Plus 和使用 Cortex-M 內存保護單元 （MPU） 來提高微控制器單元 （MCU） 安全性的方法。第 1部分介紹了一些介紹性概念：MMU 與 MPU、對安全性、保護目標、MPU-Plus 快照、Cortex-v7M 和 v8M 以及 MPU 操作的日益增長的需求。

圖 1：分區

圖 1 說明了我們為安全而努力實現的軟件結構。在此圖中，橢圓表示隔離的分區。粗線以上的分區以umode（非特權或用戶模式）運行，粗線以下的分區以pmode（特權或保護模式）運行。粗線表示非特權操作和特權操作之間的界限。這種隔離由 Cortex-M 處理器架構強制執行。它是安全可靠的，除非我們做錯了什么。

粗線上方是兩個應用程序分區和一個中間件分區。當然，實際系統可能有更多的 umode 分區。這里的目標是實現一個 umode 分區與另一個分區的完全隔離。然后穿透一個分區不會使黑客能夠穿透其他分區，因此可以控制違規行為。每個 umode 分區是一組一個或多個 utask。utask 構成了與其他分區中的任務隔離的基礎，但不是與自己分區中的任務隔離的基礎。umode 分區具有強隔離能力。因此，應盡可能將易受攻擊的代碼（如驅動程序、中間件和應用程序代碼）放入 umode 分區。

粗線以下是安全啟動、pcode、smx、SMX RTOS 內核和安全分區。這些由 pcode 組成。當然，實際系統可能有更多的 pmode 分區。目標是也將 pmode 分區彼此隔離。但是，這種隔離不如 umode 隔離那么強，后面會討論。

安全啟動

當系統啟動或重新啟動時，處理器以 pmode 啟動，并且位于 Secure Boot 分區中。

圖 2：安全啟動

如圖 2 所示，安全啟動軟件進行基本的硬件和軟件初始化，加載代碼，如有必要，創建啟動操作所需的任務，然后啟動調度程序。在啟動調度程序之前，沒有任何任務正在運行。啟動調度器后，系統以任務模式運行，第一個以最高優先級調度的任務正在運行。其他分區進行自己的初始化。出于結構和安全原因，最好將安全引導分區中的代碼最小化。在圖 2 中，安全引導加載程序以黃色顯示。這些可以從許多來源獲得，并且超出了本文的范圍。綠色顯示的代碼是系統和應用程序代碼。

smx

SMX RTOS由smx 內核和中間件組成。SMX 被拆分，因此 smx 內核在 pmode 下運行，而 SMX 中間件在 umode 下運行。MPU-Plus 與 SMX、eheap ? 和某些其他產品捆綁在一起時，構成SecureSMX ?。

smx分區包含smx內核和SVC Handler、PendSV Handler等相關軟件。它以 pmode 運行，以便將其與可能已損壞的 umode 分區強烈隔離。MPU-Plus 擴展了 smx 以添加安全功能。有關這些的更多信息，請參閱：

smx 用戶指南， Ralph Moore，Micro Digital， Inc.

smx 參考手冊， Ralph Moore， Micro Digital， Inc.

我們發現，除了添加 MPU-Plus 之外，還需要對 smx 本身進行大量修改，盡管 smx 已作為嵌入式內核使用了 30 年！中間件產品也需要進行重大修改。安全似乎正在給嵌入式系統軟件帶來范式轉變。

安全

最后是安全分區和保險庫。Vault 是我們存儲珠寶（加密密鑰、密碼、驗證碼、證書等）和現金（私人數據）的地方。如果 pmode 被破壞，避難所就會彈開，王國就會消失。因此，保護 Vault 至關重要，只有包含加密、身份驗證和其他安全任務的安全分區才能訪問 Vault。

加密和身份驗證軟件已從 SMX 中間件產品中移出到安全分區中。因此，只有安全軟件才能訪問 Vault。

代碼

pcode 分區包含中斷服務例程 （ISR）、鏈接服務例程 （LSR） 和其他必須處于 pmode 的代碼。這是系統、中間件和應用程序代碼的混合體。在實際系統中，這可能會分為系統分區和應用程序分區。它可能包含一些 ptask 以及 ISR 和 LSR。同樣， smx 錯誤

Manager、smx_EM（） 和錯誤恢復代碼不是任務。因此，此分區中的大部分代碼都在當前任務的上下文中運行。

處理中斷會帶來特殊的安全問題，這將在第 3 部分中討論。

任務

utasks 可以提供高級別的隔離。這主要是因為他們無法訪問 MPU。MPU 加載了允許任務訪問的區域，包括訪問權限（例如只讀、從不執行等），但任務無法更改它們。如果背景區域打開，它在 umode 中無效。然而，一切都不是桃子和奶油——還有堆問題和函數調用問題，這些將在后面討論。

任務

與 utasks 相比，ptasks 提供的隔離性較弱。這是因為一旦 ptask 被破壞，惡意軟件只需一個步驟即可關閉 MPU 或打開其背景區域 （BR）。然后 MPU 區域沒有效果。MPU 在 pmode 中毫無防備，而在 umode 中則堅不可摧。

但是，ptasks 可以通過捕獲許多黑客技術（例如堆棧或緩沖區溢出、嘗試從堆棧或緩沖區執行等）并在黑客獲得實際控制權之前觸發 MMF 來幫助挫敗攻擊者。然后，MMF 處理程序可以刪除滲透的任務并重新創建它，希望系統操作中只有一個小問題。它還可以報告事件，這有助于發現和減少代碼漏洞。

ptasks 對于捕獲編程錯誤也很有用，并且可以成為通向 utasks 的有用步驟。

基本操作

MPU 控制

內存保護陣列 （MPA） 是一組要在任務切換上加載到 MPU 中的區域；每個任務都有一個 MPA。任務的索引用于在內存保護表中查找其 MPA，mpt［indexsmx_TaskCreate（） 將當前（父）任務的 MPA 復制到正在創建的任務。如果 ct 是 ptask，它可以通過以下方式更改任務的 MPA：

smx_TaskSet（任務，SMX_ST_MPA，tp）；

其中 tp 指向任務的 MPA 模板。

前述如圖3所示。在該圖中，MPA0、1和2共享模板mpa_tmplta。因此，三個對應的任務共享相同的區域。因此，它們很可能在同一個分區中。請注意，MPA3 使用模板 mpa_tmpltb。因此，相應的任務很可能在一個單獨的區域中。第五個任務尚未創建，其 MPA 也未加載。

圖 3：模板、MPA 和 TCB

MPA 中的插槽與 MPU 中的動態插槽一樣多。大多數插槽都充滿了鏈接器命令文件中定義的靜態區域（一個乏味的過程）。但是，某些插槽具有指向在運行時動態創建的區域數組的指針。這些將在第 4 部分中詳細討論。具有最高優先級的頂部 MPU 正在使用的插槽是為任務堆棧區域保留的。任務棧是在創建任務時從主堆動態創建的，或者在調度任務時從棧池中獲取。在任務運行時，對 MPU 的任何更新也會對其 MPA 進行，因此在任務切換期間無需保存 MPU 內容。

創建靜態區域是一個費力的過程。例如，對于代碼區域，有必要識別特定分區或特定任務所需的所有功能，包括子例程。Pragma 被插入到代碼中，以將所有這些放入一個唯一的代碼部分，例如：

#pragma default_function_attributes = @“.ut1a_text”

無效 tm05_ut1a（無效）

{

smx_SemSignal（sbr1）;

}

#pragma default_function_attributes =

然后在鏈接器命令文件中定義一個塊來保存此部分和相關部分，例如：

定義塊 ut1a_code，大小 = 1024，對齊 = 1024 {ro section .ut1a_text，ro section .ut1a_rodata}；

區域在鏈接器命令文件中定義，并在其中放置塊，例如：

定義區域 ROM = mem：［從 0x00200000 到 0x002FFFFF］；

放入 ROM {block t2a_code， ro section .tmplt， block ut1a_code， block ut2a_code， block ut2b_code};

回到代碼中，定義了 MPA 中的一個槽：

#pragma section = “ut1a_code”

MPA mpa_tmplt_ut1a =

{

。..

RGN（3 | RA（“ut1a_code”） | V， 代碼 | RSI（“ut1a_code”） | EN， “ut1a_code”），

。..

};

所有這些都是針對一個模板中的一個 MPU 區域完成的——顯然是一個費力的過程。上面顯示的模板宏（例如 RGN（））可以減少工作并有助于減少錯誤。因為有些語句在代碼中，有些在鏈接器命令文件中，所以該過程容易出錯。不僅如此，很容易為代碼區域遺漏一個晦澀的子程序或為數據區域遺漏變量，從而在調試期間導致煩人的 MMF（在調試的早期階段關閉 MMF 的一個很好的理由）。

系統調用

ptasks 可以直接調用所有的 smx 和 system 函數，但是 utasks 不能直接調用它們，因為它們必須在 pmode 中執行。而是使用 SVC N 指令。對于 umode 代碼，將包含 smx 和系統原型函數的 xapi.h 頭文件替換為 xapiu.h 頭文件。后者將 smx_ 調用映射到 smxu_ 調用，這些調用是調用 SVC N 的 shell 函數，其中 N 是系統調用 ID。但是，限制通話，對于 umode 是禁止的，會產生 Privilege Violation 錯誤。受限調用只能通過 pcode 進行。例如，utasks 不需要 smx_HeapInit（），如果從惡意軟件調用，可能會導致系統損壞，因此沒有 smxu_HeapInit（）。定義了一組合理的受限調用。然而，該集合可以根據需要針對特定應用進行擴展或收縮。

圖 4：系統調用

圖 4 說明了 utasks 和 ptasks 的系統調用機制。SVC Handler 使用 N 作為索引，通過 SSR 跳轉表到 smx 系統服務例程（SSR）。SSR 在 pmode 中執行，然后將結果返回給 SVC Handler。SVC 處理程序將此結果返回給 smxu shell 函數，后者將其返回給 utask。所有這些細節對調用者都是隱藏的，看起來就像是進行了正常的函數調用。umode 中不允許的系統調用會導致分支到特權沖突錯誤管理器 （PVEM），而后者又會調用 smx 錯誤管理器 （EM）。

請注意，來自 ptask 的 smx 調用直接轉到 SSR，并且沒有不允許的服務調用。

本系列的下一部分將討論分區問題，包括堆使用、函數調用 API、中斷、父子任務和任務本地存儲。

審核編輯：郭婷