作者：Ralph Moore

現在，網絡釣魚、弱密碼、身份驗證不足和特權執行不力等唾手可得的成果正在消失，黑客被迫尋找滲透公司網絡和設備的新方法。目前連接到企業網絡的大量完全易受攻擊的設備為此提供了肥沃的機會。到目前為止，設備安全性已經得到了很多討論，但很少采取行動。這種情況即將改變。

在過去的幾年里，我們一直致力于為基于MCU的設備開發安全的RTOS，特別是Cortex-v7M和v8M。該RTOS具有許多創新功能來遏制和限制安全漏洞。本文的目的是介紹這些功能，并說明通過使用它們可以實現高度安全的設備。

SecureSMX 基于 smx 實時、多任務內核，該內核在過去 30 年中為數百個嵌入式系統提供了可靠的操作。它提供靈活而廣泛的解決方案，使OEM能夠在合理的時間和成本限制內將有效的安全保護整合到其嵌入式和物聯網設備中。這種安全性的基礎是隔離分區，這對于此類系統來說并不容易實現。分區有許多優點：

允許硬件強制分離特權和非特權代碼，并控制對系統服務、數據、內存區域和 I/O 寄存器的訪問。

使其他保護成為可能，例如運行時限制和限制對對象的訪問。如果沒有硬件強制分區，則可以輕松繞過此類限制。

允許將稀缺的程序員人才集中在加強最關鍵的分區上。

防范零日漏洞。這些通常賣得很多錢，是國家安全機構嚴密保護的秘密［參考文獻1］。但是，黑客也可以使用未修補的已知漏洞，因為無論哪種方式，他最終都會進入一個孤立的分區，在不碰到絆線的情況下，他可以做的事情受到很大限制。如果非關鍵分區已被滲透，系統將繼續執行其基本功能。這使安全團隊有時間解決問題，而不是總是追趕。

使用定義良好的接口的模塊化代碼的良好編程實踐的硬件實施。這不僅可以生成更高質量的代碼，還可以縮短集成和調試時間。

僅分區恢復。當黑客觸發眾多檢查中的任何一項時，會立即發生內存管理故障 （MMF） 異常。這可用于關閉分區，然后重新初始化它。這比重新啟動整個系統更可取，因為它不會停止正常運行。

僅分區更新。如果沒有其他移動，則可以單獨更新分區。這樣就無需將任務關鍵型代碼暴露給內部攻擊。更新僅限于受到攻擊的易受攻擊的分區。舊代碼和受信任的代碼通常已經過詳盡的測試，很少需要更新。內部攻擊是一個比人們普遍認為的更大的問題［參考文獻2］。

沒有安全性是完美的。但是，為系統添加安全性可以減輕損害和潛在責任。

目標

這種安全的實時操作系統既旨在促進現有系統的安全改進，也旨在作為新系統的安全基礎。開發人員可以根據需要使用盡可能多或盡可能少的功能。易受攻擊的代碼（如開源 ［Ref 3］ 或網絡堆棧和新開發的軟件包）可以通過一系列定義明確的步驟與系統的其余部分隔離。隔離可以根據需要盡可能強，如果需要，可以施加限制。同時，系統的其余部分可以繼續按原樣運行，基本上保持不變。因此，對于開始被黑客入侵的現有系統，有一個解決方案。

操作

SecureSMX利用Cortex-v7M和v8M架構的所有硬件安全功能，除了它不需要TrustZone。重要的是將操作硬件分離為處理程序模式 （hmode）、特權任務模式 （pmode） 和非特權任務模式 （umode）。內存保護單元 （MPU） 用于限制每個任務可以訪問的內存。SVC 指令用于允許 umode 任務訪問系統服務。背景區域 （BR） 僅在 hmode 中使用。

目前典型的嵌入式系統完全在hmode下運行。第一步是將代碼分為在 pmode 中運行的任務（ptasks）和系統服務（例如 RTOS）、異常處理程序和在 hmode 中運行的 ISR。任務在啟用 MPU 和禁用 BR 的情況下運行。每個 ptask 都可以有一個唯一的內存保護陣列 （MPA），當 ptask 開始運行時，該陣列會加載到 MPU 中?；蛘撸蝿湛梢允褂媚J的 MPA。此時，任務之間會獲得一些隔離，具體取決于每個任務具有自己的 MPA 的程度以及 MPA 區域定義的緊密程度。為了實現更大的隔離，可以將任務移動到 umode。然后，系統的所有其余部分都受到硬件強制 pmode 屏障的保護。

分區應用程序

什么是分區？

分區由它們包含的一個或多個任務定義。他們沒有控制塊。通常，分區對應于系統的邏輯部分，通常稱為模塊，例如文件系統。像這樣的分區通常有一個頂級任務和一個或兩個子任務來幫助它。但是，根據特定系統，分區可以由多個頂級任務組成，并且可以包括多個模塊。例如，在給定的系統中，所有中間件或所有 utask 都可以合并到單個分區中。分區靈活性允許在投入的工作量和實現的安全性之間實現最佳權衡。

v7M 分區

眾所周知，Cortex-v7M MCU 的分區很難實現，因為 v7M MPU 要求每個區域大小是 7 的冪，并且要與其大小保持一致。顯然，這可能導致嚴重的內存浪費，并導致v4M MPU在很大程度上被嵌入式軟件社區拒絕［參考文獻《》］。對于安全MCU設計來說，這是一個不幸的挫折。但是，我們發現了許多克服此問題的方法，這些方法已合并到我們的新RTOS中。以下段落詳細描述了這些方法，以便呈現令人信服的圖片。

定義節

系統中的每個任務都需要為其使用的每個活動 MPU 插槽提供一個區域。通常所有 MPU 插槽都處于活動狀態，因此每個任務需要 8 個區域。盡管某些區域可能在任務之間共享，但通常需要為典型系統定義大量區域。區域的定義始于在代碼中使用雜注 ［腳注 i］ 來定義包含在區域（例如.sys_data）中的部分（例如.sys_bss和.sys_data）。區域的各個部分可能分布在多個模塊中，但鏈接器將區域的所有部分合并到單個區域塊中。

鏈接器命令文件

我們開發了一種簡單的方法來創建 v7M 鏈接器命令文件。在其頂部，系統的所有區域的大小都以十六進制定義。要成為 1 的冪，區域大小必須只有一個非零數字，并且該數字必須是 2、4、8 或 5。因此，很容易避免區域大小錯誤。在區域大小下方，每個區域塊的大小 = region_size*8/6、8/7、8/8 或 8/1，其對齊方式 = region_size，以及它包含的部分。這種方法的一個很好的功能是，在開發過程中，當鏈接器報告某個區域已被超出時，將其大小提高 8/5 或上升到下一個 8*8/8 的冪（如果它已經是 《》/《》）是一件簡單的事情。

模板、內存保護陣列和任務

海洋保護區模板

每個任務都有一個內存保護陣列、MPA 或默認 MPA，在調度任務時將其加載到 MPU 中。任務的 MPA 是在創建任務后從其 MPA 模板生成的。任務可以有自己的 MPA 模板，也可以與其他任務共享一個模板。MPA 模板是使用特殊宏定義的，這些宏允許每行定義一個由 RBAR、RASR 和 region_name組成的區域。（region_name僅在調試期間使用。子區域禁用是根據區域塊大小自動生成的（例如，如果區域塊大小 = region_size*5/8，則設置 SRD 5、6 和 7）。這避免了用戶的復雜性，同時最大限度地減少了區域大小。

縮小區域之間的差距

鏈接器按指定的順序將區域塊分配給內存。這可能會導致塊之間出現較大的間隙，從而浪費大量內存。為了解決這個問題，運行 MPUPacker? 以找到區域塊的最佳排序。然后更改順序以匹配鏈接器命令文件中，并再次運行鏈接器。為了幫助將代碼和數據分配給區域，可以運行 MPUMapper? 來修改映射文件以顯示每個符號所在的區域。這在開發過程中非常有幫助，可以修復 MMF 并檢查系統是否分區良好。

一般來說，我們發現內存浪費可以保持在 20% 以下，通常是 10%。如果需要，還可以使用其他方法來減少內存浪費。但是，如果有足夠的內存，則在分區之間分布未使用的內存是有利的，因為這有助于僅分區更新。

v8M 分區

Cortex-v8M 解決了區域問題，只要求區域是 32 字節的倍數，并在 32 字節邊界上對齊。因此，上述許多措施對于v8M不是必需的，盡管基本方法是相同的。然而，v8M 引入了一個新問題：如果分區重疊，就會發生 MMF。這為任務堆棧、PMSG 和動態區域創造了一個致命弱點。可以通過從與主堆不同的堆中分配它們來解決，但需要努力避免被這種不必要的體系結構缺陷所捕獲。

來自 umode 的系統服務

來自 umode 的系統服務

ptasks 可以進行直接系統調用，因為它們在其 MPA 中具有sys_code和sys_data區域。這些區域將替換為 utask 的 ucom_code 和 ucom_data，這些區域無法進行直接的系統服務調用。相反，utasks 必須使用由 SVC n 指令觸發的 SVC 異常，其中 n 表示 256 個服務調用之一。utask 代碼中包含了一個特殊的頭文件，用于將服務調用映射到具有相似名稱的 shell 函數。枚舉定義 n 的值，SVC 處理程序 SVCH（） 使用相同順序的跳轉表跳轉到所需的服務調用。對于每個調用 SVC n 的系統服務，ucom_code都有一個 shell 函數，其值由枚舉定義。此系統可以輕松添加或刪除服務呼叫。

當 SVC n 執行時，它會導致創建異常幀，切換到 hmode，切換到主堆棧，并啟動 SVCH（）。SVCH（） 從異常幀重新加載 r0-r3，將參數 5 及以上從任務棧復制到主棧，并通過跳轉表（在 sys_code 中）調用系統服務。當系統服務完成時，SVCH（） 會進行一些調整，然后將異常返回到調用點。返回值（如果有）在 r0 中。除了生成故障異常之外，這是 utask 可以在 hmode 中訪問代碼的唯一方法。

來自 umode 的系統調用開銷相當小，并且不會顯著影響系統性能，因為系統調用不頻繁。明顯有害的系統調用無法通過 SVC n 使用。在某些情況下，從 umode 調用時，系統調用的有害部分會被禁止。此外，某些服務（如中斷啟用和禁用）無法從 umode 工作。中斷禁用和啟用必須替換為中斷掩碼和取消掩碼，并提供一種方法來限制可以從 utask 中屏蔽或取消屏蔽哪些 IRQ。

通常，umode 分區將僅使用少量的系統服務調用。因此，提供了一種方法，允許為分區定義自定義枚舉、自定義跳轉表和自定義 shell 函數。這通過最大限度地減少對ucom_code的訪問來改善隔離。一般來說，標準的枚舉、跳轉表和 shell 函數應該縮減到 umode 分區實際需要的，從而節省內存并提高安全性。

雖然沒有必要，但 ptasks 也可以訪問系統服務的 SVCH（），而不是直接調用。這在 pmode 到 umode 的轉換過程中提供了一個步驟。

任務 vs. u任務

支持 PTASKS 主要是為了簡化將分區從 PMODE 移動到 uMode 的過程。但是，它們可以與提高系統可靠性的utask一樣有效。將任務轉換為 ptasks 后，通過分配 MPA，可能會出現潛在的錯誤，例如未初始化的指針、堆棧溢出等。

為了安全起見，utasks比ptasks更好。這是因為如果一個任務被穿透，只需要一條指令就可以關閉MPU。這在 umode 中是不可能的，因此 umode 提供了更強的安全性。此外，pmode 屏障使得幾乎不可能從 umode 訪問 pmode 和 hmode。

門戶

為了實現完全分區隔離，有必要引入門戶。這是因為函數 API 要求函數本身可供用戶訪問，這違反了隔離。

門戶提供間接 API，用于將一個分區中的服務與其他分區中的調用方隔離。調用照常進行，但它們使用 smx 消息來指示服務器任務執行服務并通過門戶返回結果。

SMX 消息由鏈接到包含實際消息的數據塊的消息控制塊 （MCB） 組成。消息可以發送到任務可以等待的消息交換。可以從消息等待的消息交換接收它們。消息可以具有優先級，并且可以按優先級順序在交易所排隊。因此，優先級較高的消息可以繞過優先級較低的消息。交換處的郵件隊列可以用作服務器的工作隊列。

受保護的郵件 （PMSG）

對于門戶，區域信息將添加到消息中，從而創建所謂的受保護消息 pmsg。當收到 pmsg 時，其區域將加載到 MPU 中的空插槽中，以及接收任務的 MPA。這允許任務訪問數據塊，但不能訪問sys_data中的 MCB。對于門戶，接收任務稱為服務器，發送任務稱為客戶端。通常，一臺服務器可能有許多客戶端?？蛻舳丝梢越o pmsg 一個優先級，當服務器接受 pmsg 時，這個優先級將傳遞給服務器。

創建門戶時，將為其提供允許訪問門戶的客戶端列表。創建過程初始化服務器控制結構，并將門戶交換句柄和門戶名稱加載到每個客戶端結構中。只有這些客戶端可以訪問門戶，因為只有他們知道將 pmsg 發送到哪里。

提供兩種類型的門戶：

免費消息門戶

免費消息門戶

For this portal when a message is sent， the exchange becomes its owner， and then the server becomes its owner when the message is received. When sent， the pmsg region is cleared in the MPU and in the client’s MPA. Thereafter， the client cannot access nor alter the message. When the server is done， it sends the pmsg to a reply exchange from which the client may retrieve it. Once sent， the server can no longer access the pmsg. Free message portals are intended for transfer of small amounts of data and commands.

Tunnel Portal

隧道門戶

隧道門戶旨在快速發送大量多塊數據。在這種情況下，客戶端保留對 pmsg 區域的所有權和訪問權限。數據塊成為客戶端和服務器分區之間的隧道，從而允許發送和接收多個數據塊。信號量用于協調操作。傳輸完成后，門戶關閉，永磁同步器釋放。

操作

對于這兩種類型的門戶，頭文件將服務器函數 API 映射到名稱略有不同的 shell 函數。此頭文件包含在進行服務器函數調用的每個客戶端文件中。每個 shell 函數創建一個包含函數 ID、參數和數據 的 pmsg，并將 pmsg 發送到門戶交換。服務器接收 pmsg 并使用 switch 語句將 ID 轉換為函數調用，進行調用，然后將函數返回回 shell 函數，shell 函數將其返回給應用程序。所有這些都對應用程序是透明的，只是操作速度較慢。

由于切換到服務器任務，門戶操作可能與直接調用有很大不同。如果 pmsg 的優先級高于客戶端，則服務將搶占并立即運行。這最像是直接服務呼叫。如果 pmsg 具有相同的優先級，則在客戶端掛起之前，服務不會運行。如果 pmsg 的優先級較低，則服務將在將來的某個時間運行。當服務是某些低優先級功能（如事件日志記錄）時，后者很有用。

免費消息門戶提供 100% 隔離;隧道門戶僅提供略少。

性能

性能很好，因為永磁同步發電機操作不需要復制永磁同步發電機數據塊（與基于 MMU 的系統不同）。實際上，數據塊可以用作客戶端中的工作緩沖區，以便進一步減少數據復制。通過增加 PMSG 數據塊的大小，性能得到了極大的提高。

以下是將我們的文件系統 （FS） 寫入同一處理器（STM32F746，Cortex-M7）上的 SD 卡的測量性能（KB/秒），與兩者都沒有。它還顯示了無復制模式的輕微增益，其中客戶端使用入口緩沖區作為工作緩沖區。

FS+SD 7969 / 4855

FS+SD+portal no copy 6788 / 4544 85% / 94%

FS+SD+portal copy 6685 / 4419 84% / 91%

使用 MPU 和門戶將讀取性能降低了 16%，將寫入性能降低了 9%，直接在客戶端中使用門戶緩沖區（無復制）時略有改進。

堆

現代嵌入式系統比過去更頻繁地使用堆。但是，如果分區共享單個堆，則無法實現隔離，因此需要多個堆。

堆堆 箱結構

eheap 是我們復雜的堆管理器，包含在 SecureSMX 中。它專為嵌入式系統而設計;它支持多個堆，并使用 bin （如 DLMALLOC）來加速分配。與 dlmalloc 不同，每個堆的箱數和箱大小是可自定義的，以滿足應用程序要求。例如，如果分區中經常需要 256 的塊大小，則可以創建僅包含此大小的 bin 。此外，eheap 可以分配兩個對齊塊的冪，并且可以分配 v7M 區域。這些對于動態區域特別有用，這是此安全 RTOS 的一項功能。eheap 的多任務版本提供每堆互斥鎖，以避免該堆的訪問沖突。

大多數任務堆棧、受保護的消息 （pmsg）、受保護塊 （pblk） 和許多系統結構都是從 v7M 系統的主堆中分配的。對于 v8M 系統，由于其非區域重疊要求，其中一些對象可能需要從另一個堆中分配。如果需要，可以為需要它們的分區創建自定義堆，例如用C++編寫的分區。Eheap 可以為小型C++對象合并小塊池，以加快操作速度。通常，分區堆比主堆簡單得多，也小得多。此外，eheap 支持自動掃描和修復每個堆及其 bin 中的斷開鏈接。

調度程序回調

大多數 RTOS 都提供 EXIT 和 ENTER 回調。前者可用于在任務掛起時保存擴展狀態，后者可用于在任務恢復時還原擴展狀態。smx 還提供 START 和 DELETE 回調。當任務首次開始運行時，前者可用于執行任務初始化并獲取任務所需的資源。刪除任務后，后者可用于釋放資源并進行任務清理。由于 DELETE 通常是 switch 語句中低于 START 大小寫的情況，因此很容易確保不會遺漏任何內容。因此，分區可以循環打開和關閉而不會泄漏，以支持僅分區恢復。

運行時限制

不幸的是，即使是完全分區隔離也不足以防止黑客攻擊。即使他無法離開分區，黑客也可以從分區內造成大量損害。一個簡單的攻擊是將分區中的任務放入無限循環中。然后，將阻止所有同等或更低優先級的任務運行。這最終可能會使任何系統崩潰。為了防止這種情況，有必要使用任務運行時限制。

不幸的是，在實時系統中，運行時間限制既是詛咒，也是祝?！?，我們不希望在緊急情況下（例如當起重機即將傾覆時）將關鍵任務戴上手銬。但是開發人員很難估計避免這種災難可能需要多少運行時間。因此，允許重要任務在沒有運行時限制的情況下運行。這一點，加上他們的高優先級，確保他們可以根據需要運行完成工作，即使在極端情況下也是如此。

受信任度較低的任務使用計數器分配運行時限制。在幀開始時，將清除所有計數器。事實證明，時鐘周期分辨率太粗糙，因此使用 CPU 時鐘。每次運行任務時，都會確定它使用的時鐘數并將其添加到其計數器中。如果這超出了任務的運行時限制，則任務將在門信號燈上掛起，無法再運行。在每次刻度時，當前任務的計數器都會更新，如果它超過其運行時限制，則任務將在門信號量上掛起。

運行時限制

在任務優先級之間取得良好的平衡已經夠困難的了，這使得任務能夠滿足其最后期限。添加固定的運行時幀只會增加此難度。相反，當空閑任務有足夠的傳遞來完成其工作時，我們會結束運行時幀。由于空閑任務的優先級最低，因此可確保所有任務都充分運行。然后，門信號燈發出信號，并恢復所有等待任務，并清除其計數器。此外，具有相同優先級的任務以與掛起相同的順序恢復。這樣可以避免任務運行中出現可能導致問題的較大間隙。

子任務共享其頂級父任務的 ［腳注 ii］ 運行時限制和計數器。如果超出限制，子任務將立即掛起。僅當父項及其其他子項嘗試在此之后運行時，它們才會掛起。為任務系列分配運行時限制比嘗試為每個任務分配運行時限制要容易得多，因為每個任務是生成的。

令 牌

在第二次世界大戰期間，家庭收到了用于肉類的紅色代幣，用于魚類的藍色代幣和用于手推車的銀代幣。通過這種方式，我們的政府控制了消費。同樣，我們需要控制分區可以使用多少每個資源以及分區如何使用該資源。我們的實時操作系統為此目的使用令牌。

句柄是存儲對象地址的內存位置，例如任務 - 即它是一個特殊的指針。令牌是句柄的地址。句柄是在鏈接時創建的，因此它們的地址在運行時是已知的。有兩種類型的令牌：HI 令牌允許創建、刪除、修改和訪問對象，LO 令牌僅允許訪問對象（例如信號量測試和信號）。程序員為每個任務編譯一個標記列表，并在創建任務后將其分配給該任務。如果未分配令牌列表，則任務不需要令牌即可訪問或修改對象。后者對于恢復任務等任務是必需的，它使受信任任務的工作更簡單。

令牌 控制信號量訪問

黑客可以從分區內部做的陰險的事情之一是一遍又一遍地創建相同的對象，直到對象控制塊池耗盡。然后，沒有其他任務可以創建該類型的對象。這被阻止如下：首先，黑客使用的任務必須具有對象的 HI 令牌。其次，一旦創建，在刪除對象之前無法重新創建對象。

另一種可能的攻擊是猜測一個句柄并用它來制造麻煩。例如，可以向另一個分區中的信號燈發出信號，從而導致該分區中的任務在不應該運行時運行。通過要求該對象的令牌來阻止此操作。

除了令牌之外，在使用之前，還會驗證所有句柄參數是否為有效句柄。每個句柄都經過范圍檢查，并檢查其 cbtype 字段。這可以防止黑客在系統服務調用中使用無效對象。

ISR 問題

Cortex-M 中一個嚴重的架構缺陷是 ISR 在 hmode 下運行。大多數 RTOS 都使情況更加復雜，它們允許從 ISR 調用內核服務。這些共同為黑客創造了一個大目標。這個目標特別誘人，因為黑客攻擊它會讓他進入 hmode，在那里他可以關閉 MPU 并訪問他喜歡的任何內容。

SMX 始終支持不同的設計理念，其中 ISR 最小化，大多數中斷處理推遲到鏈路服務例程 （LSR）。它們按調用的順序運行，并排在所有任務之前。LSR 不受優先級反轉問題的影響，因此比任務更適合延遲中斷處理。此外，LSR 開銷要少得多。當處理時間不重要時，LSR 可以簡單地向信號燈發出信號，延遲中斷處理任務在其中等待。最小化 ISR 大小既可以減小目標大小，又可以讓 ISR 程序員更專注于使代碼難以破解。

有三種類型的 LSR 可用：tLSR、pLSR 和 uLSR。tLSR 是受信任的 LSR。它們在hmode中運行，開銷非常低。它們應盡可能簡短，例如僅發出信號量。pLSR和uLSRs被稱為安全LSR。每個都有自己的堆棧和自己的MPA，并且表現得像一個微任務。從 LSR 隊列調度時，LSR 的 MPA 將加載到 MPU 中，其堆棧將成為操作堆棧。因此，安全 LSR 可以在它們服務的分區中運行，這會將中斷處理的一小部分以外的所有內容都帶到它所屬的分區中。這對uLSR來說是一個巨大的收獲。

開發人員通常編寫進行內核調用的長 ISR。安全 LSR 允許將盡可能多的代碼移動到 LSR 中，然后將 LSR 移動到其相關分區中。因此，如果黑客闖入ISR代碼，而不是處于hmode狀態，他發現自己處于隔離的umode分區中并受到其限制。

需要注意的一件有趣的事情是，安全的 LSR 可能使用相同的 MPA 作為分區中的任務，或者它可能更像一個子任務，并且具有一些共享區域和一些唯一區域（例如 IO）。安全LSR具有非常小的控制塊，通常需要非常小的堆棧。此外，它們在 ISR 和任務之間優先運行。因此，它們提供了一種有趣的IO處理方法，比通常的ISR方法更安全。

SMX感知

smxAware 為 IAR C-SPY 調試器提供內核感知。當與 SecureSMX 一起使用時，添加了 MPU 和 MPA 顯示器。這使得在跟蹤 MMF 時更容易查看區域大小和屬性。此外，門戶操作顯示在事件時間線圖中，MPU 區域顯示在內存映射概述圖中。

事件監控

監視大量內核事件，例如服務調用、ISR 運行、LSR 運行、任務操作、錯誤等。每個事件的相關信息都存儲在事件緩沖區 EVB 中。此外，還可以定義和記錄用戶事件。可以過濾日志記錄，以便 EVB 不會太快填滿。EVB 可以定期上傳到安全監控站點，在該站點中，特殊軟件會查找可能表明攻擊正在進行中的異常行為。如果是這樣，安全控制可以采取適當的操作，例如關閉分區。

監控大型系統所有元素的運行可能是阻止逃避安全機制并緩慢滲透計算機網絡的高度復雜攻擊的唯一方法。

目標

在最優系統中，盡可能多的代碼已經從 pmode 移動到彼此高度隔離的 umode 分區，門戶用于分區間通信，所有不受信任的任務都是運行時和令牌限制的，延遲中斷處理在安全的 LSR 中完成，任務關鍵型代碼和數據受到 pmode 屏障的雙重保護。

雖然這個目標對于新設計來說是可以實現的，但對于現有設計來說不太可能是可行的。將所有不受信任的代碼移動到單個 umode 分區并對其應用一些限制可能是一個適當的解決方案。SecureSMX 專門設計用于提供實施部分解決方案的靈活性。它還旨在允許漸進式改進，其中安全團隊一次修復一個問題，從而在不破壞銀行的情況下逐步實現安全性改進。

重要的是要認識到，仍然可以使用其他安全措施，例如信任根、安全啟動、安全更新、加密和代碼改進。相反，它提供了堅實的安全基礎，并提供了許多處理安全問題的新選項。

將應用程序移植到 SecureSMX

為了簡化現有應用程序移植到我們的安全實時操作系統，FRPort 和 TXPort 包含在其中。它們提供了移植功能，可將應用程序中使用的 90% 以上的 FreeRTOS 和 ThreadX 服務調用移植到等效的 smx 服務調用。計劃建設更多港口。嘗試在其他 RTOS 上運行 SecureSMX 是行不通的，因為它與 smx 的富內核功能緊密綁定，而這些功能在其他 RTOS 中是缺失的。將應用程序移動到它應該導致更好的操作，并允許訪問上面討論的所有安全功能。

未來

到目前為止，許多設備已被黑客入侵，但黑客主要關注網絡釣魚等唾手可得的果實，以進入計算機網絡。然而，隨著公司采用更好的安全軟件和更好的安全實踐，唾手可得的果實開始消失。如前所述，下一個主要黑客目標可能是已經連接到計算機網絡的數千臺未受保護的設備。這些很容易被黑客入侵。

設備供應商的高層管理人員需要決定他們是想現在開始采取謹慎的步驟，還是稍后雇傭一支軍隊來處理對其設備的攻擊。法院將來可能會裁定安全性不足構成疏忽，因此設備制造商將面臨損害賠償［參考文獻5］。這可能會使許多公司倒閉。即使這種情況沒有發生，可證明的安全性也可能成為許多類型設備的主要銷售點。

縱觀廣泛的軟件圖景，在大多數嵌入式系統中，可能只有大約10%的軟件完成關鍵工作。此代碼是公司業務的本質。它可能寫得很嚴格，經過徹底測試，經過現場驗證，因此不太可能改變。剩下的 90% 的代碼是第三方、開源和新開發代碼的混合體，并且可能帶有許多漏洞。如果不進行分區，此代碼中任何地方的黑客攻擊都會暴露整個系統，從而助長贖金攻擊和關鍵數據的盜竊。像這樣讓公司的膽量變得脆弱是沒有意義的。

此外，應該預計內部攻擊將變得更加普遍。當提供大筆資金時，員工的忠誠度可能是可以協商的。任務關鍵型代碼是公司皇冠上的明珠。它應該被鎖起來，除了少數高度信任的員工之外，所有人都無法訪問。由于任務關鍵型代碼可能不需要更新，因此不需要將其包含在僅分區更新中。如果更新中不包含任務關鍵型代碼，則無法篡改，這為避免災難性攻擊提供了一些希望。

結論

我們的新RTOS旨在提供一套靈活的工具和結構，以提高現有基于MCU的系統以及新系統的安全性。它允許以最少的受信任的遺留代碼修改來做到這一點。其固有的靈活性允許首先解決最重要的問題，從而逐步提高系統安全性。

如果將 SecureSMX 用作新系統的基礎，則很可能可以在很少或沒有進度或開發成本增加的情況下實施強大的安全性。這是因為它提供了設計實踐的硬件實施，經證明可以減少集成和調試時間。而下游的回報，在安全保護方面，是巨大的。對于上面介紹的所有功能，SecureSMX 與 SMX 的代碼大小增加約為 20 KB。考慮到典型MCU上的大片上閃存，以及與典型應用代碼的大小相比，這是可以忽略不計的。一個更大的問題是節省寶貴的片上SRAM，我們提供了工具和技術來最大限度地減少由于v7M架構上的對齊而導致的浪費，如減少區域之間的差距一節所述。

編輯：黃飛