這是由四部分組成的系列文章的第一部分,介紹了獨特的產品 MPU-Plus? 以及使用 Cortex-M 內存保護單元 (MPU) 實現改進的微控制器單元 (MCU) 安全性的方法。
模壓傳感器與模壓單元
幾十年來,大型操作系統在具有MMU的微處理器上使用隔離過程來實現分離和系統安全性。我們最近增強的產品 MPU-Plus 使用帶有 MPU 的微控制器為 SMX 實時操作系統添加了類似的功能。這已經為Cortex-M架構完成了,并將在將來擴展到其他架構。
內存管理單元 (MMU) 與完整操作系統 (OS) 一起使用,為進程提供隔離的虛擬內存。進程是獨立編譯和鏈接的,然后由操作系統(如 Windows 和 Linux)單獨加載和運行。進程到進程的隔離已經足夠好了,如果一個進程被惡意軟件感染或由于任何其他原因開始出現故障,操作系統通常可以將其關閉,而對其他進程幾乎沒有損害。因此,安全性很好。MMU的使用是經過充分研究和充分理解的。MMU使用的缺點是它通常需要高性能處理器和非常大的內存。
快速、耗電的處理器和巨大的內存與大多數嵌入式系統的要求不兼容。此外,完整的操作系統沒有許多應用程序所需的實時響應時間。因此,大多數嵌入式系統使用低功耗、中等性能的微控制器單元 (MCU) 和實時操作系統 (RETOS)。與完整的操作系統系統相比,這些系統通常具有較小的內存。出于安全考慮,許多 MCU 提供內存保護單元 (MPU),這些單元無法像 MMU 那樣創建虛擬地址空間。
在大多數嵌入式系統中,我們處理的是分區而不是進程。這個想法基本上是相同的 - 分區包括一個或多個任務,并為系統執行特定功能。就像進程一樣,希望將分區彼此隔離,以便在一個分區被穿透或開始出現故障時,可以停止它,同時對系統其余部分的損害最小。不幸的是,這在使用 MPU 的嵌入式系統中并不像在使用 MMU 的完整操作系統系統中那樣容易實現。這里最大的挑戰是所有MCU軟件都被編譯并鏈接到一個可執行文件中。此外,MPU 還施加了自己的限制。MPU的安全性使用沒有得到很好的研究,也沒有得到充分的了解,并且涉及許多復雜的權衡,特別是因為嵌入式系統通常具有較小的存儲器,中等性能的處理器,功率限制以及對確定性實時性能的需求。
對安全性的需求日益增加
如果它如此困難,為什么要打擾呢?這似乎是嵌入式系統行業在過去幾十年中采用的方法。不幸的是,這還不夠長,因為嵌入式系統正在快速連接到物聯網(IoT)中。因此,一旦被隔離,無防御的嵌入式系統就可以通過黑客高速公路(又名互聯網)進行訪問。這意味著麻煩。
保護目標
保護的主要目標是保護受信任的關鍵軟件和數據免受不太受信任的非關鍵軟件的侵害,這些軟件可能會感染惡意軟件或有缺陷。受信任軟件的示例包括 RTOS、異常處理程序、安全軟件(例如加密、身份驗證、安全啟動、安全更新等)和任務關鍵型軟件。不太受信任的軟件的示例是易受惡意軟件攻擊的代碼,例如協議堆棧、設備驅動程序、SOUP 和未充分測試的代碼。
第二個目標是檢測入侵和錯誤并關閉它們,以便關鍵系統操作不會受到威脅,敏感數據也不會被盜。處理入侵和錯誤可以通過停止和重新啟動滲透的任務來處理,或者可能需要停止并重新啟動整個系統。
第三個目標是最大限度地減少受信任的代碼量,因為仔細編寫少量代碼更容易。在非特權模式下運行更多代碼可增加分區隔離,從而提高可靠性。
必須實施的保護程度取決于特定系統的安全和安全要求及其面臨的威脅。MPU-Plus 提供一系列安全服務,可實現適合給定系統的保護級別。此外,隨著系統分布范圍越來越廣,因此更容易受到攻擊,在將來的版本中可以增加保護。MPU-Plus旨在促進逐步的保護改進。
超強快照
MPU-Plus的主要目的是增強基于SMX?實時操作系統的多任務系統的安全性。MPU-Plus 為幫助實現更好的安全性所做的主要工作是:
允許為每個任務定義不同的MPU模板;
在任務切換期間處理MPU切換;
提供 SVC API 以允許非特權代碼調用特權服務;
限制哪些服務可以從非特權代碼調用以及它們可以做什么;
允許分配受保護的塊和消息;
在特權模式下運行SMX RTOS和系統代碼,在非特權模式下運行中間件和應用程序代碼;
允許任務具有特權或非特權。
作為構建安全性的平臺。
MPU-Plus 有兩個主要設計目標:
更輕松地轉換舊代碼以使用 MPU 和 SVC API。
允許開發人員專注于保護策略,而不會被 MPU 特性和其他硬件細節所困擾。
實施良好的保護策略已經夠困難的了。細節層面的過度復雜化不僅令人沮喪,還可能導致采用不太理想的系統保護。
Cortex-v7M
Cortex-v7M 處理器架構于 2005 年推出,適用于中型嵌入式系統。從那時起,半導體行業開發了數千種不同的Cortex-v7M微控制器單元(MCU)。它們用于設備制造商開發的數以萬計的產品中;迄今為止,已經出貨了數十億個芯片。它是迄今為止占主導地位的MCU架構(70%的市場份額),因此也是我們支持的架構。
Cortex-v7M體系結構提供以下安全功能:
特權模式。
主管呼叫 (SVC) 指令。
內存保護單元。
第一種是通過三種處理器操作模式實現的:
處理程序模式:ISR、錯誤處理程序、SVC 處理程序和 PendSV 處理程序的特權模式。只能通過中斷或異常進入此模式。
特權線程模式:特權任務在此模式下運行。它只能通過設置 CONTROL.nPRIV = 0 從處理程序模式輸入。
非特權線程模式:非特權任務在此模式下運行。可以通過設置 CONTROL.nPRIV = 1 從上述兩種模式中的任何一種模式輸入它。
為了減少接下來討論中的冗長,我們使用以下縮寫術語:前兩種模式統稱為pmode,第三種模式稱為umode。p 前綴可以解釋為特權或受保護;u 前綴可以解釋為非特權或用戶。在 pmode 中運行的代碼和任務稱為 p 代碼和 ptask;在 umode 中運行的代碼和任務稱為 ucode 和 utasks
Cortex-M架構的關鍵方面是,只能通過中斷或異常輸入 pmode。SVC N 指令會導致此類異常。它可以從帶有 8 位參數 N 的 umode 執行。這允許從 umode 進行系統調用,其中 N 指定要調用的函數。被調用的函數在 pmode 中執行。SVC 也可以從模數執行。
MPU 為 M 區域提供 M 插槽。每個區域都有起始地址、大小和訪問參數,例如只讀 (RO)、讀/寫 (RW)、從不讀取 (XN) 等。如果 MPU 中的至少一個區域不允許內存訪問,則會生成內存管理故障 (MMF)。MMF 是導致 MMF 處理程序運行的異常,該處理程序通常會停止有問題的任務并確定要執行的操作以進行恢復。
圖 1 顯示了一個只有 4 個插槽的示例 MPU。(大多數 MPU 有 8 個插槽,有些有 16 個插槽。存儲在 MPU[0] 中的區域是任務代碼的 RO 區域。MPU[1] 區域是代碼的 RO 區域,與其他任務通用。存儲在 MPU[2] 中的區域是用于數據的 RW 和 XN 區域。最后一個區域是任務堆棧,也是 RW 和 XN。下面顯示了可選的任務本地存儲 (TLS),它可以是任務堆棧區域的一部分,可用于本地任務數據。由于僅提供了指向 TLS 的指針,因此數據必須是結構或數組。它具有與任務堆棧相同的屬性。此任務無法訪問內存的白色區域。
v7 MPU 的一個嚴重缺點是區域大小必須是 2 的冪,并且區域必須在其大小邊界上對齊。這一要求可能是v7 MPU使用率低的主要原因,但可以克服。實際上,MPU的最大缺點是插槽不足。幾乎所有的 Cortex-M 處理器都有帶有八個插槽的 MPU。當一個人開始為實際分區創建區域時,八個是不夠的 - 12個可能剛剛好。一些處理器有16個插槽;強烈建議將這些用于新設計。我們同時支持 8 個和 16 個插槽 MPU,但我們的重點是前者,因為它們是迄今為止最常見的。
盡管 Cortex-v7M MPU 具有顯著的局限性,使其難以使用,但它是 Cortex-v7M 處理器可用的硬件內存保護的唯一手段,硬件保護是唯一有效防止黑客攻擊的保護措施。因此,重要的是要找到有效使用它的方法,以實現現代嵌入式系統所需的可靠性,安全性和安全性。
Cortex-v8M
Cortex-v8M 架構是在幾年前宣布的。迄今為止,使用它的處理器很少。v8 MPU 將區域大小和對齊要求大大降低到 32 字節的倍數。這對于內存有限的嵌入式系統很有幫助。但是,MPU 插槽的數量在 v8 體系結構中保持不變。希望半導體供應商能夠選擇16個而不是8個插槽,至少在非安全狀態下是這樣。我們將很快支持 v8 MPU。
Cortex-v8M 體系結構還提供了一個名為 TrustZone 的新功能,該功能允許安全和非安全狀態。信任區安全狀態適用于密鑰和其他私有數據的存儲。但是,在安全狀態下運行代碼可能不值得額外的代碼復雜性和調試難度。阿姆說不然,所以我們得看看。此外,我們預計大多數設備制造商都需要一個同時適用于 v7 和 v8 處理器的安全解決方案。
審核編輯:郭婷
-
mcu
+關注
關注
146文章
16987瀏覽量
350299 -
操作系統
+關注
關注
37文章
6737瀏覽量
123190 -
微處理器
+關注
關注
11文章
2247瀏覽量
82311
發布評論請先 登錄
相關推薦
評論