Cortex-M v7 內存保護單元 （MPU） 很難使用，但它是 Cortex-M3、-M4 和 -M7 處理器可用的硬件內存保護的主要手段。這些處理器廣泛用于中小型嵌入式系統。因此，學習有效地使用 Cortex-M v7 MPU 以實現現代嵌入式系統所需的可靠性、安全性和安全性非常重要。

以前的博客介紹了 MPU和術語、MPU 多任務處理和定義 MPU 區域。在第一篇博客中，定義了特權任務 （ ptasks） 和非特權任務 （ utasks）。前者以特權線程模式運行，后者以非特權線程模式運行［2］。任務的模式umode由其任務控制回（TCB）中的標志確定，并在實時操作系統（RTOS）調度程序調度時生效。umode可以在創建任務后隨時設置標志pmode。

ptasks可以直接調用系統服務，但是utasks不能。有兩個原因：

保護 RTOS 及其數據免受utasks. 這可能是未知譜系的軟件 （SOUP），或者它可能容易受到惡意軟件的攻擊（例如，TCP/IP 堆棧）。

限制此軟件可以使用的 RTOS 服務。不希望utasks能夠執行可能損害正常系統操作的操作，例如斷電或刪除任務。

本博客討論了實現上述保護的機制。應該注意的是，MPU 安全性的主要目標是將盡可能多的應用程序代碼放入utasks.

utask MPA 地區

每個任務都有自己的內存保護數組 （MPA），它是從 MPA 模板初始化的。一個utask（例如ut2a）的典型 MPA 模板如下：

該模板在創建任務后加載到任務的 MPA 中，然后在分派該任務時加載到 MPU 中。MPA［0］任務堆棧的區域是在任務首次啟動時定義并放入的。因此，上面utask可以訪問它自己的堆棧、它自己的代碼和數據區域、公共代碼和數據區域，而沒有其他任何東西。區域 5、6 和 7 被禁用或特權。因此，這utask被阻止直接訪問系統服務和數據。后者適用于 all utasks，盡管它們的模板可能不同。

umode 服務

utasks必須使用軟件中斷 （SWI） 應用程序編程接口 （API） 來訪問系統服務，并且他們永遠無法直接訪問系統數據。此外，只有不受限制的系統服務才能被utasks. 這些障礙有助于保護操作系統 （OS） 免受不受信任的代碼的影響。

SWI API 是通過 Cortex-M SVC 指令“ SVC n”實現的，其中n指定要執行的系統服務。

對于 smx RTOS 內核，頭文件 ，xapi.h包含所有 smx 服務的原型函數。在開頭包含此文件pcode允許它訪問其中任何一個。對于ucode，xapiu.h被定義。它由 。 中允許的系統服務的映射宏組成umode。例如：

這個宏覆蓋了函數原型，xapi.h因此對于應用程序模塊的其余部分，它不是直接調用系統服務，而是調用一個 shell 函數：

該外殼函數用于調用n == ID系統服務的 SVC 指令。NI（Not Inline） 是一個由編譯器阻止函數內聯的宏。請注意，shell 函數具有相同的名稱，只是它的前綴smxu_不是smx_. 貝殼位于該ucom_code區域中，因此它們可以通過utasks.

應用程序模塊可以以pcode開頭ucode，也可以完全是pcode或ucode。無論哪種方式，ucode都以：

在那之后不能直接調用任何系統服務。以上所有內容都是在編譯時完成的，因此變成了硬編碼，因此可以抵抗惡意軟件和錯誤，特別是如果代碼位于 ROM 中。

混合pcode/ucode模塊很方便，因為系統的功能部分通常會有一個根任務，它是一個ptask為該部分創建、初始化和啟動所有其他任務的任務，其中大部分可能是utasks. 因此，所有相關的任務都可以放在一起。內在的想法是系統部分的某些任務可能是執行關鍵任務功能的精心構建的任務。這些任務可能是ptasks。系統部分的其他任務可能正在執行非關鍵功能，例如收集要發送到云的統計信息。這些將是utasks.

有些任務可能會隨著項目的發展而開始存在ptasks并被遷移到。utasks通常更容易在其中調試代碼pmode然后將其移至umode. 此外，任務可以啟動ptasks并執行pcode，設置自己的umode標志，然后重新啟動自己utasks并執行ucode。

另一個有趣的特性是xapiu.h可以部署多個文件并由不同的utasks. 這允許不同級別的信任。因此，與可信度較低的任務相比，可信度更高的任務可以訪問更多的 RTOS 服務。這允許收緊 SOUP 或高度易受攻擊的任務的絞索。但是，這僅在編譯時有效。為了防止惡意軟件，還需要有對應于不同xapiu.h文件的不同跳轉表（參見下面的圖 5）以及為每個任務選擇跳轉表的機制。

utask服務調用機制

如上所述，軟件中斷 API 的基本概念非常簡單。但是當調用的系統服務可能導致任務切換時，事情就變得更加復雜了——尤其是對于 Cortex-M 架構，它要求 RTOS 調度程序駐留在PendSV_Handler. 同樣復雜的是，處理程序以特權模式運行并使用系統堆棧 （SS）［3］ 而不是當前的任務堆棧 TS。

如下圖所示，SVC_Handler（）由 SVC 指令調用并以處理程序模式運行：

開始運行時，由于處理器堆疊SVC_Handler（），系統服務參數處于 TS 中。處理程序將參數 0 到 3 移動到thru中，并將第 5 個參數（如果有）移動到系統堆棧的頂部，SS（這是系統服務期望找到這些參數的地方）。然后通過跳轉表調用系統服務（SSR），使用傳遞給它的索引（ID）（見上文）。r0r3SVC_Handler（）ssrt［］n

系統服務正常執行并返回SVC_Handler（），將系統服務返回值從r0TS 移動到正確位置。處理器執行的處理程序返回操作將TS 中所有堆疊的寄存器取消堆疊，因此返回值以r0.

如果系統服務導致任務調度程序需要運行 （ sched 》 0） 或中斷導致鏈接服務例程 （LSR） 調度程序需要運行 （ lqctr 》 0），PendSV_Handler（） 則將被掛起。在這種情況下，處理器尾鏈 ［4］ 從SVC_Handler（）到PendSV_Handler（由圖中的虛線所示），而不是返回到utask.

在這種情況下，控制不會返回到utask尚未調用的點，而是返回到在PendSV_Handler（）。 這可能會導致當前任務被掛起，而另一個任務被恢復運行（如圖右側所示）。搶占任務可以是 autask或 a ptask。最終，掛起的utask將被恢復、取消堆棧，并從調用點繼續運行，前提是它沒有被搶占任務停止或刪除。（注意：以上所有操作都是在特權模式下完成的，因此可以防止受到感染的惡意軟件的侵害ucode。）

ptask服務調用機制

相比之下，下圖顯示了從ptask.

請注意，這更簡單（更快）：SVC_Handler（）不涉及。ptask直接調用系統服務，如果設置sched，PendSV_Handler（）則掛起。從那里開始，操作與 a 的操作相同utask。

交叉操作

無論系統服務是從utasks還是調用，系統服務的操作都是一樣的ptasks。例如，autask可以測試一個信號量并在它上面掛起。Aptask可以發出信號量并且utask將恢復。或相反亦然。Aptask可能具有比 a 更高或更低的優先級utask，調度程序將根據其優先級調度它（特權在這里沒有優先級！）。不同的是，ptask執行受信任的代碼 （ pcode） 并且通常可以完全訪問內存、外圍設備和系統服務，而utask執行非特權代碼 （ ucode） 并且只能訪問 MPU 允許的內容。此外，MPU 只能通過 更改pcode。

以免擔心ptasks不受約束的代理，請注意，即使啟用了后臺區域，也可以阻止通過 MPU 訪問區域。因此，對一個任務進行讀/寫 （RW） 的區域可能對另一個任務是只讀 （RO） 并且從不對兩者執行 （XN）。另一方面，ptasks確實可以直接訪問所有 smx 服務。隨著系統安全性的加強，應考慮限制ptasks以及utasks.

審核編輯：郭婷