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

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

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

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

　　使其他保護成為可能，如運行時限制和限制對對象的訪問。如果沒有硬件強制分區，這種限制很容易被繞過。

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

　　防止零時差。這些通常可以賣到很高的價格，并且是國家安全機構的高度機密［參考文獻1］。然而，黑客也可以使用未打補丁的已知漏洞，因為無論哪種方式，他都將在一個隔離的分區中結束，在不觸動絆線的情況下，他可以做的事情受到很大的限制。如果一個非關鍵分區被穿透，系統將繼續執行其基本功能。這給了安全團隊時間來解決問題，而不是總是玩追趕游戲。

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

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

　　僅分區更新。如果沒有其他東西移動，分區可以單獨更新。這消除了將關鍵任務代碼暴露給內部攻擊。更新僅限于易受攻擊的分區。遺留和可信代碼通常已經過全面測試，很少需要更新。內部攻擊是一個比普遍認為的更大的問題［參考文獻2］。

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

　　目標

　　這個安全RTOS的目的是促進現有系統的安全改進，并作為新系統的安全基礎。開發者可以根據需要使用或多或少的特性。易受攻擊的代碼，如開源［參考文獻3］或網絡堆棧和新開發的包，可以通過一系列明確定義的步驟與系統的其余部分隔離。隔離的強度可以根據需要而定，如果需要，可以施加限制。同時，系統的其余部分可以繼續運行，基本不受影響。因此，對于開始被黑客攻擊的現有系統，有一個解決方案。

　　操作

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

　　當前典型的嵌入式系統完全運行在hmode中。第一步是將代碼分成運行在pmode （ptasks）中的任務和運行在hmode中的系統服務（例如RTOS）、異常處理程序和ISR。ptasks在MPU使能、BR禁用的情況下運行。每個ptask可以有一個唯一的存儲器保護陣列（MPA ），當ptask開始運行時，該陣列被載入MPU。或者，ptask可以使用默認MPA。在這一點上，根據每個任務擁有自己的MPA的程度以及MPA區域定義的緊密程度，任務獲得了一定程度的相互隔離。為了實現更好的隔離，可以將任務轉移到umode中。那么系統的所有其余部分都將受到硬件實施的保護pmode勢壘。

　　分區應用程序

　　什么是分區？

　　分區是由它們包含的一個或多個任務定義的。它們沒有控制塊。通常，一個分區對應于系統的一個邏輯部分，通常稱為組件，如文件系統。像這樣的分區通常有一個頂層任務和一兩個子任務來幫助它。然而，為了適應特定的系統，一個分區可以由多個頂層任務組成，并且可以包括多個模塊。例如，在一個給定的系統中，所有的中間件或所有的utasks可能被合并到一個單獨的分區中。分區靈活性允許在投入的精力和實現的安全性之間達到最佳的平衡。

　　v7M分區

　　眾所周知，Cortex-v7M MCU的分區很難實現，因為v7M MPU要求每個區域的大小是2的冪，并且大小一致。顯然，這可能導致嚴重的內存浪費，并導致v7M MPU在很大程度上被嵌入式軟件社區拒絕【參考文獻4】。這對于安全MCU設計來說是一個不幸的挫折。然而，我們已經找到了許多方法來克服這個問題，這些都被納入我們的新RTOS。以下段落詳細描述了這些方法，以便提供一個令人信服的畫面。

　　定義部分

　　系統中的每個任務都需要一個區域用于它所使用的每個活動MPU插槽。通常所有MPU插槽都是活動的，因此每個任務需要8個區域。盡管一些區域可以在任務之間共享，但是對于典型的系統，通常需要定義大量的區域。在代碼中，區域的定義從使用pragmas［腳注i］開始，以定義部分（例如。.sys_bss和。 sys_data），它們包含在該區域中（例如sys_data）。一個區域的各個部分可能分布在幾個模塊中，但是鏈接器將一個區域的所有部分組合成一個模塊區域塊。

　　鏈接器命令文件

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

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

　　MPA模板

　　每個任務都有一個內存保護數組，MPA，或者默認MPA，當任務被分派時，它被加載到MPU中。任務的MPA是從其MPA模板在任務創建之后。一個任務可能有自己的MPA模板，或者與其他任務共享一個模板。MPA模板是使用特殊的宏定義的，它允許每行定義一個區域，由RBAR、RASR和region_name組成。（region_name僅在調試期間使用。）子區域禁用are自動地從區域塊大小生成（例如，如果區域塊大小= region_size*5/8，則設置SRD 5、6和7）。這為用戶避免了很多復雜性，同時最小化了區域大小。

　　縮小地區之間的差距

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

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

　　v8M分區

　　Cortex-v8M解決了區域問題，只要求區域是32字節的倍數，并在32字節邊界對齊。因此，盡管基本方法是相同的，但是上述許多措施對于v8M來說是不必要的。然而，v8M引入了一個新問題：如果分區重疊，就會出現MMF。這給任務堆棧、pmsgs和動態區域帶來了致命的弱點。可以通過從不同于主堆的堆中分配它們來解決這個問題，但是需要注意避免被這個不必要的架構缺陷所困擾。

　　來自umode的系統服務

　　來自umode的系統服務

　　ptasks可以直接進行系統調用，因為它們有系統代碼和sys_data他們海洋保護區內的區域。這些區域被替換為ucom _代碼和ucom_data對于utasks，它不能直接進行系統服務調用。相反，utasks必須使用SVC異常由觸發SVC n指令，其中n表示256個服務調用中的一個。utask代碼中包含一個特殊的頭文件，用于將服務調用映射到具有相似名稱的shell函數。一個枚舉定義了n的值，一個跳轉表，以同樣的順序，被SVC處理器SVCH（）用來跳轉到所需的服務調用。在ucom_code中，每個系統服務都有一個shell函數，它使用enum定義的n值調用SVC n。該系統使添加或刪除服務呼叫變得容易。

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

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

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

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

　　普塔斯克vs尤塔斯克

　　支持ptasks主要是為了方便將分區從pmode移動到umode。然而，在提高系統可靠性方面，它們和utasks一樣有效。將任務轉換為ptasks后，通過分配MPAs，潛在的bug如未初始化指針、堆棧溢出等。很可能會出現。

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

　　門戶網站

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

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

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

　　受保護的消息（pmsg）

　　對于門戶，區域信息被添加到消息中，創建所謂的受保護的郵件， 血清促性腺激素。當接收到一個pmsg時，它的區域被加載到MPU的一個空槽中，接收任務的MPA。這允許任務訪問數據塊，但不能訪問sys_data中的MCB。對于門戶，接收任務稱為計算機網絡服務器發送任務稱為客戶。通常，一臺服務器可能有許多客戶端。客戶機可以給pmsg一個優先級，當它接受pmsg時，這個優先級將被傳遞給服務器。

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

　　提供了兩種類型的門戶：

　　免費信息門戶

　　免費信息門戶

　　對于這個門戶，當消息被發送時，交換成為它的所有者，然后當消息被接收時，服務器成為它的所有者。發送后，MPU和客戶端MPA中的pmsg區被清零。此后，客戶端既不能訪問也不能更改消息。當服務器完成時，它將pmsg發送到應答交換，客戶端可以從應答交換中檢索它。一旦發送，服務器就不能再訪問pmsg。免費的消息門戶旨在傳輸少量的數據和命令。

　　隧道洞口

　　隧道洞口

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

　　操作

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

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

　　免費消息門戶提供100%隔離；隧道入口只提供了一點點。

　　表演

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

　　以下是在相同的處理器（STM32F746，Cortex-M7）上，使用MPU和portalss與不使用MPU和portal的情況下，將我們的文件系統（FS）寫入SD卡的性能測量值（KB/sec）。它還顯示了非復制模式的輕微增益，在這種模式下，客戶端使用門戶緩沖區作為工作緩沖區。

　　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

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

　　eheap堆倉結構

　　eheap是我們包含在SecureSMX中的完善的堆管理器。它是專門為嵌入式系統設計的；它支持多個堆，并且使用垃圾箱，比如dlmalloc，來加速分配。與dlmalloc不同，每個堆的倉的數量和大小是可定制的，以滿足應用程序的要求。例如，如果一個分區經常需要256的塊大小，那么可以創建一個只包含這個大小的bin。此外，eheap可以分配2的冪的對齊塊，并且可以分配v7M區域。這些對于動態區域特別有用，這是安全RTOS的一個特征。eheap的多任務版本為每個堆提供了一個互斥體，以避免該堆的訪問沖突。

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

　　調度程序回調

　　大多數RTOSs提供退出和進入回調。前者可用于在任務掛起時保存擴展狀態，后者可用于在任務恢復時恢復擴展狀態。smx還提供啟動和刪除回調。當一個任務第一次開始運行時，前者可以用來進行任務初始化和獲取任務需要的資源。當任務被刪除時，后者可以用來釋放資源和進行任務清理。因為在switch語句中，DELETE通常是START case下面的一個case，所以很容易確保沒有遺漏任何內容。因此，分區可以無泄漏地循環打開和關閉，以便支持僅分區恢復。

　　運行時間限制

　　不幸的是，即使完全分區隔離也不足以抵御黑客。即使黑客無法從分區中逃出來，他也可以從分區內部進行大量破壞。一種簡單的攻擊是將分區中的任務放入一個無限循環中。那么所有同等或更低優先級的任務都被阻止運行。最終，這可能會導致任何系統崩潰。為了防止這種情況，有必要使用任務運行時間限制。

　　不幸的是，在實時系統中，運行時限制可能是一種詛咒，也可能是一種祝福——例如，我們不希望關鍵任務在緊急情況下被束縛，比如當起重機即將傾覆時。但是開發人員很難估計需要多少運行時間來避免這樣的災難。所以重要的任務可以不受運行時間限制地運行。這一點，再加上他們的高優先級，確保他們可以運行所需的時間來完成工作，即使在極端的情況下。

　　不太可信的任務用計數器分配運行時限制。在一幀開始時，所有計數器都被清零。結果是節拍分辨率太粗糙了，所以改用CPU時鐘。每次任務運行時，它使用的時鐘數被確定并添加到它的計數器中。如果這超過了任務的運行時限制，任務將在門信號量再也跑不動了。在每一次滴答，當前任務的計數器被更新，如果它超過了它的運行時間限制，任務在門信號量上被掛起。

　　運行時間限制

　　很難在任務優先級之間取得良好的平衡，這使得任務能夠在截止日期前完成。添加一個固定的運行時框架只會增加這個難度。相反，當空閑任務有足夠的次數來完成它的工作時，我們就結束運行時幀。由于空閑任務的優先級最低，這確保了所有任務都充分運行。然后門信號量被發信號通知，所有等待的任務被恢復，它們的計數器被清零。此外，相同優先級的任務以暫停時的順序恢復。這避免了任務運行中的大間隙，這可能會導致問題。

　　子任務共享其頂級父任務的［腳注ii］運行時限制和計數器。如果超過限制，子任務將立即掛起。只有當父對象和它的其他子對象試圖在此之后運行時，它們才會被掛起。給任務族分配運行時限制比試圖給每個任務分配運行時限制要容易得多，因為它是衍生的。

　　代幣

　　在第二次世界大戰期間，家家戶戶都收到紅色的代幣買肉，藍色的代幣買魚，銀色的代幣買手推車。這樣，我們的政府控制了消費。類似地，我們需要管理一個分區可以使用多少資源，以及該分區如何使用該資源。我們的RTOS為此使用代幣。

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

　　控制信號量訪問的令牌

　　黑客可以從分區內部做的一件陰險的事情是一遍又一遍地創建同一個對象，直到對象控制塊池耗盡。那么任何其他任務都不能創建該類型的對象。這被阻止如下：首先，黑客使用的任務必須有一個對象的HI令牌。第二，一旦創建，該對象在被刪除之前不能被重新創建。

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

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

　　ISR問題

　　Cortex-M中一個嚴重的架構缺陷是ISR運行在hmode中。大多數RTOSs都允許從ISR調用內核服務，這就更復雜了。這些共同為黑客創造了一個巨大的目標。這個目標特別有誘惑力，因為入侵它會讓他進入hmode，在那里他可以關閉MPU并訪問任何他喜歡的東西。

　　smx一直支持不同的設計理念，其中ISR被最小化，大多數中斷處理被推遲到鏈接服務例程（LSR）。這些任務按調用的順序運行，并在所有任務之前運行。LSR不受優先級反轉問題的影響，因此比任務更適合延遲中斷處理。LSR的開銷也少了許多。當處理時間不重要時，LSR可以簡單地向一個信號量發送信號，讓一個延遲的中斷處理任務等待。最小化ISR大小既減少了目標大小，又允許ISR程序員更專注于使代碼難以破解。

　　有三種類型的LSR:tlsr、pLSRs和uLSRs。tLSRs是信任LSRs。它們在hmode中運行，開銷非常低。它們應該盡可能的短，比如僅僅發一個信號量。pLSRs和uLSRs被稱為安全LSR。每個都有自己的棧和自己的MPA，行為就像一個微任務。當從LSR隊列調度時，LSR的MPA被加載到MPU中，并且它的棧成為操作棧。因此，安全LSR可以在它們所服務的分區中運行，這使得除了一小部分之外的所有中斷處理都進入了它所屬的分區。這對uLSRs來說是一大收獲。

　　開發人員通常編寫長的ISR來調用內核。安全LSR允許將盡可能多的代碼轉移到LSR，然后將LSR轉移到相關的分區。因此，如果黑客侵入了ISR代碼，而不是在hmode中，他會發現自己在一個隔離的umode分區中，并受到其限制。

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

　　smxAware

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

　　事件監督

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

　　監控一個大型系統的所有元素的操作可能是阻止高度復雜的攻擊的唯一方法，這些攻擊規避安全機制并慢慢滲透到計算機網絡中。

　　目標

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

　　雖然這一目標在新設計中是可以實現的，但在現有設計中不太可能實現。將所有不可信的代碼轉移到一個umode分區中并對其進行一些限制可能是一個合適的解決方案。SecureSMX專門設計用于提供實施部分解決方案的靈活性。它還被設計為允許增量改進，其中安全團隊一次解決一個問題，從而實現漸進的安全改進，而不需要傾家蕩產。

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

　　將應用移植到SecureSMX

　　為了方便將現有應用程序移植到我們的安全RTOS，它包含了FRPort和TXPort。這些提供了移植功能，將應用程序中使用的90%以上的FreeRTOS和ThreadX服務調用移植到等效的smx服務調用。更多的港口正在規劃中。試圖在其他RTOS上運行SecureSMX是行不通的，因為它與SMX的豐富內核特性緊密相關，而這些特性是其他RTOS所沒有的。將應用程序轉移到it部門應該會帶來更好的操作，并允許訪問上面討論的所有安全特性。

　　未來

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

　　設備供應商的高層管理人員需要決定是現在就開始采取謹慎的措施，還是以后雇傭一支軍隊來應對對他們設備的攻擊。將來，法院可能會裁定不充分的安全措施構成疏忽，因此設備制造商將面臨損害賠償［參考文獻5］。這可能會讓許多公司破產。即使這不會發生，可證明的安全性也可能成為許多類型設備的主要賣點。

　　縱觀整個軟件行業，在大多數嵌入式系統中，可能只有大約10%的軟件執行關鍵工作。這個準則是公司業務的精髓。它可能是經過嚴格編寫、徹底測試和現場驗證的，因此不太可能改變。其余90%的代碼混合了第三方、開源和新開發的代碼，并且很可能存在許多漏洞。如果沒有分區，這段代碼中任何地方的黑客攻擊都會暴露整個系統，從而為勒索攻擊和竊取關鍵數據提供便利。讓一家公司如此脆弱是沒有道理的。

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

　　結論

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

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

　　審核編輯：黃飛