ARM TrustZone技术简介 -- 4 （TrustOS）

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来说这个有点超过实际需要了。