TrustZone

在产品设计之初，我们就要有一个基本的“隔离”的概念。

需要考虑的问题大致有以下两个方面：

• 产品中的哪些功能和模块应该放在安全区？（这部分代码往往是核心且精简，且经过安全审查的，安全区的内容不允许非安全区的代码触碰）；
• 哪些功能应该放在非安全区？（这样放在非安全区中的代码，即使出现安全漏洞（例如栈溢出漏洞等等）后被攻击，MCU的安全区中的资源和外设也无法被攻击者利用）。

令人头疼的HardFault

对于MCU工程师，TrustZone是一个比较新的技术，在开发调试过程中，由于TrustZone配置问题，时常遇到各种意料之外的HardFault，我们也经常调侃，这个TrustZone也太安全了，连我们自己都进不去。

其实这种问题往往是由于在开发阶段，我们实际的行为和我们对TrustZone的划分不一致。

平常我们认为正常的行为与操作，对于TrustZone来说，已经越界违规了，这就会使TruztZone触发HardFault，并阻止违规行为。

在这种情况下，我们就需要找到导致HardFault的原因，并调整对于TrustZone的配置。

获取违规操作的蛛丝马迹

Cortex M33内核本身在SAU中提供了两个寄存器：SFSR(Secure FaultStatus Register，安全故障状态寄存器)和SFAR(Secure Fault Address Register，安全故障地址寄存器)。

SFSR寄存器用于指示出现错误的类型，例如非安全区试图访问安全区，从安全区到非安全区的非法跳转等。

SFAR寄存器用于指示出现错误的内存地址。

看起来这两个寄存器就足以帮助我们查到问题的根源了。但是，有时候，我们从这两个寄存器拿到了错误的原因和地址，仔细检查后发现无论是安全区还是非安全区的程序，都没有显式的访问这个地址。

这是由于MCU系统愈发复杂，总线上除了M33内核之外，还有许许多多的其他的外设，例如DMA，USB等等。肇事者不一定是M33内核，还有可能是其他的外设，例如DMA。

下面是一种常见的事故：被划分为非安全的DMA在工作中访问了安全区的地址或外设，违反了TrustZone的配置，造成了HardFault。

恩智浦的MCU在SOC层面提供了一个安全AHB控制器，能够帮我们侦查肇事现场，找出肇事者的蛛丝马迹。

其实原理很简单，安全AHB控制器提供了三个寄存器，SEC_VIO_INFO_VALID，SEC_VIO_MISC_INFO和SEC_VIO_ADDR。

SEC_VIO_INFO_VALID用来指示肇事现场，这个寄存器中存储了肇事现场的AHB 的端口号(port number)，端口号与外设的对应关系参见用户手册的”Memory map overview”章节。

每一个AHB端口都相应有一个SEC_VIO_MISC_INFO寄存器，用来指示肇事的信息，例如违规操作是读操作引起的还是写操作引起的等等，最重要的是会指出肇事者的身份：

每个AHB端口还有一个SEC_VIO_ADDR，用来指示肇事现场的地址。

有了上述信息，我们就捉到了真正的肇事者。在开发阶段，我们就可以利用这些信息去调整我们的TrustZone的配置。

更进一步

当然，上述功能不只能在开发阶段帮我们排查HardFault。我们也可以利用这个机制在产品出厂之后为我们提供防御措施。

产品出厂后，当我们检测到由TrustZone产生的HardFault的原因之后，可以将其记录，以便于后续分析。如果设备有联网能力，可以将其传输至服务器。利用这些信息我们可以发现产品的哪些模块受到了攻击，方便我们后续针对性地进行OTA升级。云端和设备本地也可在此时检测镜像以及存储介质的完整性，以检查程序和存储介质是否被恶意篡改。

小结

综上所述，利用SAU和安全AHB控制器调查HardFault的方法并不复杂，NXP的MCUXpresso SDK也提供了一个完整的demo。

以LPC55S69为例，demo的路径如下：SDK\boards\lpcxpresso55s69\trustzone_examples\secure_faults。

这个demo中，人为制造了几种TrustZone触发HardFault的案例，在产生HardFault后，使用上文描述的方法，处理相关寄存器并打印事故信息。

通常来说，在开发阶段，我们可以参考demo中HardFault的处理代码，按需移植到自己的工程中。