TrustZone技術在物理上可以把一個ARM處理器核分時複用為兩個不同的處理器，在處理器的非安全部分執行的是標準的Linux系統，而在另外一側執行的是安全強相關的功能。而由於ARM  TrustZone的硬體隔離作用，其相互之間的互動只能通過機器指令SMC來使能切換，而實際的切換過程由ARM提供的TrustFirmware BL31 來提供 。

在硬體外部裝置劃分的過程中，一般情況下IRQ交由非安全側處理，而ARM特有的FIQ則交由安全側去處理，其具體哪些硬體和記憶體能夠被安全側和非安全側訪問可以通過硬體暫存器的配置來進行。

當需要由比如Linux向安全側的OS傳遞請求等資料時，其本質是通過一塊實體記憶體對映到非安全側和安全側來達成資料共享的作用的。而此部分記憶體也是整個TrustZone技術暴露在外的最大攻擊面，由於資料互動的特有需求，所以這種在非安全側和安全側傳遞資料的記憶體是一定能夠被兩邊訪問的，作為資訊傳遞的媒介，其和作業系統的使用者態程式和核心態功能進行互動的記憶體十分相似，而我們能夠拿來保護 使用者態和核心態資料互動的記憶體保護方法也大部分都能夠直接應用在保護 非安全側和安全側系統之間記憶體互動之上。

在早期的TrustZone應用中，在安全側的處理邏輯大部分只是簡單的函式呼叫，例如非安全側將要加密的資料傳送到安全側，安全側通過函式呼叫同步的完成加密或者解密的流程，並把結果返回給安全側。這種實現相當的簡單高效，能夠處理很多簡單的應用場景，但是其同時也存在很多問題：

1. 不利於擴充套件，無法簡單的將安全側提供的基礎服務抽象成通用業務，使開發新的安全功能變得漫長複雜

2. 沒有很好的功能性隔離

3. 不能完成一個相對複雜的組合功能

4. 難於維護

所以在現在的TrustZone業務中已經很少這類同步函式的安全業務實現了，其一般是由一個很精簡的核心 + 一組基礎的使用者態業務基礎服務庫 + 數個安全應用程式 組成

而TrustOS有很多不同的實現，在業界比較先進的方法是類似kinibi的微核心實現，（拋開微核心和巨集核心之間持續數十年的戰爭不談，單純在業務隔離，防止崩潰的連鎖反應上，微核心應該是毫無疑問要好於巨集核心的），而對於TrustOS這種不考慮通用性，只是為了隔離，業務安全的場景來說，微核心是最好的實現，所以三星採用的Trustonic的kinibi就是一個完整的微核心實現，其底層的非安全側和安全側切換使用的就是ARM的TrustFirmware，但是其TrustOS的核心是一個很精簡的微核心，從而來保證不同的安全業務崩潰，底層系統服務崩潰不會對其本身的穩定性造成影響。（這點對於TrustOS來說至關重要）

實際上對於TrustOS的安全性要求只在一般的水平上，對於系統來說其重要依靠縮減功能達成減小攻擊面結合硬體保護隔離來達成增強系統安全性的目的，而如果要單純在作業系統純軟體領域達成安全還是需要參考軍標....比如

https://en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security

這個才是真的對系統安全的極致追求，但是這類系統的應用面很窄一般用在導彈，飛機如F22 這類系統之上，所以對於一個一般的TrustOS來說這個有點超過實際需要了。