隨著Nordic、微芯(Microchip)、新唐科技(Nuvoton)、恩智浦半導體(NXP)、意法半導體(ST)與瑞薩電子(Renesas)等公司相繼推出基於ARMv8-M的微控制器(MCU)後，即時作業系統(Real-Time Operating System, RTOS)供應商需要更新他們的RTOS，以支援供ARMv8-M使用的TrustZone。
儘管在應用面此一遷移相對直截了當，但RTOS的更新由於架構上的困難度，例如增加TrustZone的安全性延伸(對於晶片執行是選配)、增加堆疊極限檢查功能(RTOS對這項的支援是選配)、程式設計師針對記憶體保護裝置(Memory Protection Unit, MPU)的新模型、EXC_RETURN值的延伸(異常轉回)等等，而涉及更多的工作。
當安謀國際(Arm)首次將TrustZone介紹給RTOS供應商時，針對RTOS應該如何在新的ARMv8-M裝置內運作，出現了許多問題。由於供ARMv8-M使用的TrustZone設計上具有高度的彈性，且RTOS在基於TrustZone系統內有許多潛在不同的運作方式，這也讓整個情況令人感到有些困惑。
不過，這些方法都各有其優點與缺點，且在真實世界的應用情況下，這些方式並非全部合理，主要原因是必須確保軟體解決方案的安全性，並且必須滿足許多應用的需求。
在那之後，2017年發表的平台安全架構(Platform Security Architecture, PSA)，讓生態系統建立安全的管理解決方案，以及各方更多自然的協作。平台安全架構的主要目標包括：提供準則與參考實現以便讓產品設計師如系統單晶片(SoC)設計師開發安全的解決方案、在市場上提升安全不再是選項的認知、提供業界安全要求的共同基礎與了解，以及讓各種應用程式介面(API)標準化而實現安全韌體、RTOS與應用程式彼此間更佳的相容性。
作為平台安全架構的一部分，可信韌體(Trusted Firmware-M, TF-M)的參考實現以開放原始碼專案提供各界使用。此外，也提供一套具有與TF-M整合範例的參考RTOS，以及具參考平台安全架構韌體的參考硬體。這些資源讓RTOS供應商得以了解設計概念，並且能更快且更正確地移植旗下的RTOS。
為了促成市場採納，其他的活動也正在執行中，包括物聯網(IoT)測試晶片與機板的開發，例如稱為Musca的雙核Cortex-M33系統、支援TrustZone的Cortex微控制器軟體介面標準(CMSIS)，以及在developer. arm.com上提供使用的各種技術資源。
ARMv8-M架構作業系統支援
在討論RTOS該如何在ARMv8-M架構內運作的技術細節前，首先要探討ARMv8-M針對作業系統(OS)支援的架構功能。
安全與非安全記憶體分區與安全性狀態支援
ARMv8-M中最顯著的強化，就是TrustZone的安全性擴充。倘若某個處理器系統執行TrustZone安全技術，其記憶體系統會分區成安全與非安全的位址空間。簡單來看，就是當處理器在安全記憶體下運行軟體時，它便處於安全狀態，可以存取安全與非安全的記憶體空間，以及當處理器在非安全記憶體下運行軟體，它便處於非安全狀態，只能存取非安全的記憶體空間。
典型基於TrustZone的系統，包含安全與非安全記憶體與週邊設備(圖1)。而記憶體空間確切的分區安排，會依裝置的不同，有所差異。安全狀態會因為直接的函數呼叫與軟體API轉回、異常/中斷登錄或離開，而出現改變(圖2)。
圖1 記憶體分區成安全與非安全區域
圖2 供ARMv8-M使用的TrustZone下的處理器狀態
架構中也定義額外的保護機制，以確保在非安全狀態下的軟體，只能透過有效登錄點或透過有效轉回，才可切換到安全狀態下的軟體。當非安全中斷發生時，這樣也可確保安全的資訊不會外洩至非安全世界中。
分組堆疊指標與堆疊極限暫存器
為了讓面積與功耗極小化，除了堆疊相關的暫存器(如堆疊指標與堆疊極限暫存器)外，安全與非安全狀態軟體會共用同樣的暫存器組(圖3)。
圖3 處理器的整數暫存器組與供ARMv8-M使用之TrustZone的分組暫存器
分組的堆疊暫存器組，可以讓安全與非安全堆疊分開。為進一步提升安全性，也增加了一些堆疊極限暫存器，以偵測並預防堆疊溢位攻擊。礙於Cortex-M23處理器(ARMv8-M Baseline)的耗電與面積預算上的限制，只能實現安全堆疊極限暫存器，至於非安全堆疊則必須仰賴非安全記憶體保護單元(Memory Protection Unit, MPU)來進行堆疊溢位保護(在有實現的情況下)。
分組SysTick計時器
Cortex-M處理器中的SysTick(系統刻點計時器)為週期性作業系統中斷，提供低面積容量的硬體，同時可以應用在其他的計時目的。在ARMv8-M架構中，SysTick計時器硬體被區分為安全與非安全SysTick，以便允許完全獨立的運作。
對於Cortex-M23處理器(基於ARMv8-M Baseline)，也有移除SysTick計時器的額外實現選項，或者只針對一個SysTick計時器進行樣例化(Instantiate)，並讓安全軟體決定要把SysTick分配給安全或非安全軟體。
分組作業系統相關異常
為了協助作業系統運作，Cortex-M處理器支援了SuperVisor呼叫(SVC)、PendSV(可懸掛的SuperVisor服務)、SysTick異常。
在ARMv8-M架構中，TrustZone安全將這些異常區分為安全與非安全異常。它們各有其可程式化的優先等級，並且能夠個別運作。例如，在安全狀態下，執行SVC指令會觸發安全SVC異常。至於在非安全狀態下，執行SVC指令則會觸發非安全SVC異常。
分組記憶體保護單元
有了TrustZone安全性延伸，記憶體保護單元(MPU)區分為安全與非安全MPU。安全MPU在運行安全軟體時使用，包括切換至安全狀態時提取安全記憶體中的指令。而非安全MPU在運行非安全軟體時使用，包括切換至非安全狀態時提取非安全記憶體中的指令。
安全與非安全MPU都是選項，且都可以獨立進行組態。例如，安全與非安全MPU的區域支援數目可能不同。
MPU的強化同時包括全新的程式設計師模型，它可以依據帶有32位元粒度的起始或結束位址，為MPU區域定義。與之前的MPU程式設計師模型相比，它具有更大的彈性。在之前版本的架構中，MPU區域的尺寸被要求必須為2的次方，且起始位址必須是區域尺寸的整數倍數。
影響硬體與軟體設計的IoT裝置需求
當審視ARMv8-M作業系統的硬體支援時，安全與非安全世界中可用的資源，幾乎是對稱的，除了非安全世界不可直接存取安全資源、保護機制的細節(如使用SG指令以標示有效的安全登錄點)，以及堆疊極限暫存器，只有在Baseline處理器如Cortex-M23處理器的安全側可用。
有了這些成組資源，看起來幾乎安全與非安全世界都可以用主機運行RTOS。不過，在物聯網的應用中，許多需求會影響軟體運作應該看起來的模樣，說明如下：
隨著物聯網裝置部署的數目增加，安全性也愈發重要。對於物聯網而言，安全性的需求包括，但不限於：關鍵資訊的保護(如個資、密碼與憑證)、預防裝置被破解並被轉換成殭屍來發動如分散式拒絕服務(Distributed Denial of Services, DDoS)等攻勢、韌體資產、避免終端用戶繞過安全性檢查(例如啟動他們尚未付費使用的功能)。
在各式各樣的物聯網裝置上，都有允許安全性韌體更新能力的強烈需求，這不只是為了錯誤修正，同時也要讓新功能能加進來。同時，韌體更新機制也必須是安全的，以確保使用中的程式影像是真實的，且未被竄改。在某些案例中，確保產品的使用者不能回覆到舊的韌體版本也是必要的，原因是舊版韌體可能有已知的安全性漏洞。
對許多軟體開商而言，選擇軟體元件的自由(如RTOS、中介軟體)是必要的。在許多案例中，軟體開發商會想用特定的RTOS/中介軟體，原因是：某些RTOS擁有特定的軟體功能或個人偏好、諸如功能安全(Functional Safety)認證的特定應用需求、既有的程式碼可簡易遷移，以及成本(例如開發人員可能想要使用不用支付權利金的軟體解決方案，或想要使用已經獲得之特定軟體元件的使用授權)。
在某些案例中，軟體開發人員也須要針對RTOS與中介軟體進行客製化，以便匹配特定的硬體組態。
由於有針對RTOS與中介軟體進行客製的必要，軟體開發商必須具有這些軟體元件的除錯能見度。
這些需求決定了微控制器設計的方式，以及RTOS在平台安全架構(PSA)下的工作方式。針對微控制器設計層面，全新基於ARMv8-M的微控制器，常常可以看到許多下列功能：
在許多情況下，微控制器裝置製造商在裝置發表之前，會想要安裝加值韌體，並在安全記憶體中安裝某些憑證，或安全的身分資訊。某些裝置會有額外的保護功能，例如防篡改功能。
有了這些需求，須要強大的保護機制以保護各種關鍵的安全性資源，而TrustZone安全性延伸，則是自然的解決方案。
在TrustZone環境中運作RTOS
當ARMv8-M架構導入RTOS供應商時，有很多人在討論RTOS應該如何在TrustZone環境下運作。傳統上，微控制器系統的安全功能是用來保護包括RTOS的特權軟體，包括特權與非特權程式碼的分離，以及MPU預防非特權程式碼存取特權軟體使用的記憶體。
因此，許多微控制器軟體開發商都會考慮使用TrustZone當成新的保護機制，它可以用來保護作業系統。有了如此的安排，一套RTOS可以使用TrustZone來預防不信賴的應用存取記憶體，還可藉由在安全狀態下運行，允許某些應用擁有更高的特權等級。
然而，當考量稍早描述過的安全性需求時，如此的方式對於安全的物聯網裝置，是不適合的。
由於軟體開發商想要使用他們自己選擇的RTOS，並想要對應用進行客製化與除錯，這意謂微控制器裝置的安全世界必須可被除錯與程式燒錄存取。也因此在如此安排下，微控制器供應商不能把製造商的憑證或安全身分資訊寫入晶片裡，因為這樣會暴露給軟體開發人員(不要忘記駭客也可以購買晶片，並進行逆向工程)。
倘若駭客在安全特權世界中侵入某一應用，該裝置可能完全被破解，也會讓裝置的快閃記憶體遭到修改，而安全開機碼也會失效或被跳過。此一裝置除非完全抹除或程式改寫，否則將無法復原。
通常，裝置的安全側需要重兵保護，原因是高價資訊的都在這裡，以及安全韌體的更新應該須要配置強大的安全防護。這意謂在一般的運作情境下，安全韌體的更新必須加以避免。但這與RTOS及中介軟體必須定期進行更新以導入錯誤修正與新功能，出現衝突。
利用既有的特權等級與基於MPU的方式，原本就可能預防不信賴的應用存取作業系統使用中的特權記憶體。因此，使用TrustZone來保護作業系統的核心，並不會帶來太多額外的好處。透過這些觀察，RTOS應該從非安全側運作，例如非安全的快閃可以輕易進行更新、安全資訊可獲得保護。倘若非安全應用或特權程式碼遭破解，駭客將無法修改快閃記憶體以及讓安全開機失效。此外，軟體開發商可以使用自己的RTOS與中介軟體，並可以針對這些軟體元件進行客製化。
此一安排，與安全軟體開發普遍採用的「最低特權」概念相吻合。藉由降低安全側的軟體數量，它可以降低駭客入侵裝置安全側的風險(也就是減少攻擊面)。事實上，此一安排對於ARM的軟體開發並不是新作法，有了Cortex-A處理器，rich OS(如Linux)在非安全世界中執行，而安全世界則只供安全關鍵軟體(如安全開機、付款應用、數位著作權管理)使用。
在基於Cortex-M的物聯網裝置中，下列的軟體元件會被期待放在安全記憶體中，包括安全開機、安全儲存應用程式介面(API)、密碼應用程式介面、除錯認證支援、生命週期狀態管理支援、韌體更新、安全服務(如雲端服務客戶端)、安全服務的安全分區管理代理者(如Trusted Firmware-M內的安全分區管理)、RTOS輔助API等等。
這雖然不是新的概念，但某種程度上它對於某些微控制器軟體開發人員，卻是典範的改變，也就是保護作業系統不再是安全功能的主要目標(在安全方面，他們有些新東西必須考量)。
讓TrustZone內部作業系統運作
儘管在非安全側運行RTOS的決定相對容易擺平，RTOS在非安全側確切的運作卻比較複雜，原因是兩側都必須執行關聯轉換(Context Switching)。
請考慮以下的案例：某一處理器系統在非安全側有RTOS，並同時擁有A應用與B應用；在非安全側的應用A呼叫安全API X；在執行安全API X時，發生非安全系統刻點異常，並將非安全側關聯轉換至應用B；以及在執行應用B時，應用程式碼呼叫安全API Y。
對於每一個軟體元件，它們擁有自己的堆疊分配(圖4)，包括：應用A具有非安全堆疊分配，並使用PSP_NS(非安全行程堆疊指標)進行堆疊運作；被應用A呼叫的API X範例，具有安全堆疊分配，並使用PSP_S(安全行程堆疊指標)進行堆疊運作；應用B具有非安全堆疊分配，並使用PSP_NS(非安全行程堆疊指標)進行堆疊運作；被應用B呼叫的API Y範例，具有安全堆疊分配，並使用PSP_S(安全行程堆疊指標)進行堆疊運作。
圖4 供ARMv8-M使用的TrustZone中，每一個呼叫安全API的執行緒，都必須具有安全堆疊分配。
由於此一安排的緣故，RTOS(在非安全側運作)的關聯轉換，必須也同時在安全側觸發PSP的關聯轉換。可以選擇的是，兩側的MPU如果要用來隔離分配給每個應用或程式庫編碼的記憶體空間，則有必要進行重組態。
此外，也需要某些額外的作業系統輔助API。例如，當系統創造出某一應用，而它如果正要呼叫某個安全API，位於安全側的韌體必須知曉新的關聯(Context)，以便分配堆疊空間給它。同樣地，倘若必須從非安全作業佇列移除某一應用，可以導入API，以允許堆疊分配可以被刪除。要不然，也可使用某種形式的堆疊記憶體管理，為一個不再活動的關聯移除安全堆疊分配。
如同稍早討論過，有必要支援不同類型的RTOS，因此作業系統輔助API需要是開放的標準。在RTOS管理下、供ARMv8-M支援碼使用的TrustZone中，這些API原本在CMSIS-5(Cortex微控制器軟體介面標準)已經定義過，這些API列於表1。
為了修改供Cortex-M處理器使用的既有RTOS，讓它可與TrustZone以及這些API一起使用，RTOS軟體開發商必須插入這些API調入，包括RTOS啟始、關聯創造與刪除、關聯轉換(在換進與換出任務中都需要)。需要的函數呼叫範例，如圖5所示。
圖5 在非安全狀態下運作之RTOS內所使用的作業系統支援API
除了API呼叫外，供非安全RTOS使用的任務控制塊(Task Control Block, TCB)須要增加新的元素，以儲存來自TZ_AllocModuleContext_S()的轉回值。這種資料類型(struct TZ_MemoryId_t)以一套參數的方式，供後續的API呼叫使用。
為了連結包含這些API的非安全專案，非安全軟體開發商必須從晶片廠或安全軟體開發商，取得輸出的函式庫(只包含安全API的符號，但不包含其內容)，並將它加入專案中。這可以讓鏈接器產生正確的函數呼叫。
當CMSIS-5專案裡創造出來的作業系統輔助API被再次使用，TF-M裡的API執行設計也改變了：在原始的CMSIS-5執行中，輔助API呼叫會處理安全的堆疊分配。例如，為了讓安全韌體知道安全API呼叫關聯要分配多少堆疊空間，TZ_AllocModuleContext_S()的「模組」參數會用在CMSIS-5上。相形之下，針對TF-M，同樣的API會忽略此一「模組」參數，然後內部處理堆疊分配(成為安全分區管理SPM的一部分)。
同樣地，TZ_LoadContext_S()與TZ_StoreContext_S()的TF-M執行，並不會直接交換安全過程堆疊指標(PSP_S)。這些API反而會讓SPM了解非安全關聯的改變，並讓SPM處理安全上下文的改變。藉由SPM動態處理記憶體分配，安全的SRAM足跡可以減少，而沒有呼叫安全API的應用執行緒，也不會消耗安全堆疊空間。
CMSIS-5作業系統輔助API與TF-M版本儘管有很大的不同，但從非安全軟體開發角度來看，API的呼叫是一樣的。
請留意，作業系統輔助API TZ_LoadContext_S與TZ_StoreContext_S並沒有處理非安全側的關聯轉換運作。非安全側的關聯轉換碼(暫存器關聯的儲存與回復，以及非安全MPU的組態交換)，大體上不受這些API影響，也因此移植至ARMv8-M所需的非安全RTOS的改變，就可以降至最低。不過，仍須某些改變。除了稍早提過的TCB改變(增加新元素)外，非安全的RTOS碼也可能需要額外的更新，原因是EXC_RETURN碼的新值，以及可選用的(增加堆疊極限的檢查，可支援程式設計人員供MPU使用的新模型)。而其他RTOS功能，如任務排程演算法與旗號(Semaphore)處理，則不受影響。
談到這裡，不得不提到TF-M提供可使用的參考安全韌體，這是開放的原始碼，可以自由下載。
針對TF-M，目前仍有各種進行中的開發，包括額外的安全服務API。可以在Trusted Firmware的官網網頁中(請參閱「開始上手」部分)，查詢到關於Trusted Firmware專案的更多資訊，包括進行中的各種開發與計畫。
軟硬體資訊俱全 產品開發立即上手
相關的合作夥伴已經開始釋出基於ARMv8-M的微控制器裝置，許多微控制器供應商已經發表產品，可瀏覽供ARMv8-M社群使用的TrustZone網頁。目前有更多可用的硬體的是Musca開發板(圖6)，這是由安謀國際開發的測試晶片，內含雙核心的Cortex-M33系統。而基於Musca-A開發板的TF-M專案範例，可以在供Musca-A使用的Keil軟體包中找到(Musca-B1軟體即將推出)。
圖6 ARM Musca開發板
近來，也發表了全新的現場可編程閘陣列(FPGA)平台，讓軟體開發商能夠在FPGA上測試基於雙核Cortex-M33的系統。稱為DesignStart FPGA on Cloud的平台，主機架於AWS雲端服務。
此外，也可參考Trusted Firmware資訊。Trusted Firmware是一種開放原始碼、開放管理的Linaro社群部門專案，另有開發狀態儀表板以及開發藍圖可做為參考。
RTOS供應商使用了這些硬體/平台/資源，針對RTOS移植至基於ARMv8-M處理器的產品，可以開始展開作業。
TrustZone廣獲採納 RTOS更新安全有保障
在全世界朝一兆個聯網裝置邁進的同時，安全性不再只是選項。由於大型微控制器供應商的最新晶片系列，已經採納TrustZone，因此RTOS開發商必須了解如何更新RTOS，以便善用安全的好處。儘管供ARMv8-M使用的TrustZone設計上極具彈性，由於RTOS可以在安全與非安全世界中運行，此一彈性也可能在RTOS的運作上造成一些困惑。
在了解非安全RTOS與安全韌體彼此間的互動、API如何使用，以及各種可用的資源之後，RTOS開發商可以確保能夠成功且無縫地遷移至可運作TrustZone的微控制器。在此同時，應用軟體開發商仍可享受選擇自己偏好的RTOS的自由，並利用安全的韌體更新，輕鬆完成RTOS的更新。
透過平台安全架構建立的共同安全性原則基礎，以及供ARMv8-M使用的TrustZone所提供的橫跨整個系統的微控制器安全性，開發商現在與過去相比，更容易取得次世代可信賴的嵌入式與物聯網裝置。
(本文作者為安謀國際資深主任工程師)