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

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

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

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

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

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

utask MPA 地區(qū)

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

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

umode 服務

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

SWI API 是通過 Cortex-M SVC 指令“ SVC n”實現(xiàn)的，其中n指定要執(zhí)行的系統(tǒng)服務。

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

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

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

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

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

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

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

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

utask服務調用機制

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

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

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

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

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

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

ptask服務調用機制

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

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

交叉操作

無論系統(tǒng)服務是從utasks還是調用，系統(tǒng)服務的操作都是一樣的ptasks。例如，autask可以測試一個信號量并在它上面掛起。Aptask可以發(fā)出信號量并且utask將恢復?；蛳喾匆嗳弧ptask可能具有比 a 更高或更低的優(yōu)先級utask，調度程序將根據(jù)其優(yōu)先級調度它（特權在這里沒有優(yōu)先級！）。不同的是，ptask執(zhí)行受信任的代碼 （ pcode） 并且通?？梢酝耆L問內存、外圍設備和系統(tǒng)服務，而utask執(zhí)行非特權代碼 （ ucode） 并且只能訪問 MPU 允許的內容。此外，MPU 只能通過 更改pcode。

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

審核編輯：郭婷