概述

Ameba SoC 采用 Arm TrustZone 技术实现硬件级安全隔离，在芯片内部建立 SPE (Secure Processing Environment，安全处理环境)。通过 TrustZone 机制，系统在物理层面将安全固件与普通应用程序隔离。当 TrustZone 保护机制使能并锁定后，即使非安全环境下的代码获得最高系统运行特权，也无法绕过底层硬件限制去窃取或篡改安全资源。

概念解析

在深入了解底层硬件机制之前，开发者需先理解以下软件层面的固件分类及其在 Ameba 异构多核架构中的对应关系：

异构多核架构：不同的处理器核心（Master）具有不同的物理安全属性：

  • Secure CPU（如 KM4TZ、CA32）：具备完整的 TrustZone 硬件扩展，可在 Secure World 和 Non-Secure World 之间动态切换，承担系统安全策略的管理职责。

  • Non-Secure CPU（如 KM4NS、KM0、KR4、DSP）：不具备安全扩展，硬件层面固定运行于 Non-Secure 状态，其发出的所有总线访问请求均默认带有“非安全”标签。

固件类型划分：在 Ameba SDK 中，系统固件被划分为两个隔离域：

  • 安全固件 (Secure Firmware)：运行于 Secure World，可访问全系统的所有资源（包括安全与非安全资源），主要负责管理核心密钥、执行加解密运算、安全启动验证以及配置系统安全边界。安全固件包括 image1 和 image3 两部分：image1 为 KM4TZ 内核的 Bootloader，在 Secure 模式下执行固件加载与校验；image3 为独立安全固件，提供安全服务。两者均运行于 Secure World。

  • 普通固件 (Normal Firmware)：在 Ameba SDK 中称为 image2，运行于 Non-Secure World，仅能访问被划分为非安全的内存和外设，或通过专用的 NSC (Non-Secure Callable) 接口向安全世界请求安全服务。常规的 RTOS、网络协议栈、业务逻辑均运行于此。

RDP 读保护：为进一步提升 image3（安全固件）的安全性，Ameba 引入了 RDP (Read Protection，读保护) 机制。TrustZone 实现运行时隔离，而 RDP 保障静态存储安全：

  • 固件加密存储：安全固件在 Flash 中以加密形式存储，运行时由硬件自动解密执行。

  • 防止物理读取：即使攻击者获取 Flash 芯片，也无法直接读取安全固件的明文内容。

  • 防止固件克隆：加密固件与芯片内部 OTP 密钥绑定，固件无法被复制到其他芯片运行。

硬件隔离机制

Arm TrustZone 通过在系统总线的发起端、传输端、接收端三个核心节点部署拦截机制，建立完整的硬件保护链路：

../../_images/trustzone_bus_arch.svg

1. 发起端 (Master)：安全状态判定

系统中所有主设备（Master）和从设备（Slave）均挂载于 AXI 总线。当 Master 发起内存或外设访问时，其安全属性判定逻辑如下：

  • CPU 主设备（如 KM4TZ）：根据当前 CPU 运行状态（Secure 或 Non-Secure），结合其内部的 IDAU（固化的安全地址映射）和 SAU（软件可配置的安全属性单元），自动为本次访问标记相应的安全标签。

  • 不具备安全扩展的主设备（如 KR4、DSP）：此类主设备硬件层面固定运行于 Non-Secure 状态，其发出的所有总线访问请求均默认带有"非安全"标签，无法发出 Secure 请求。

  • 具备安全扩展的主设备（如 GDMA、Crypto Engine 等 IP）：此类外设没有 SAU 单元，其安全属性完全依赖专属配置寄存器设定。若需发出 Secure 请求，必须由 Secure CPU（KM4TZ）预先配置其安全控制寄存器，赋予 Secure 权限。否则该设备发出的所有总线请求都是 Non-Secure 请求。

2. 传输端 (Bus)：安全属性传递

AXI 总线协议包含专门的标准信号位用于传递访问的特权与安全属性，其中核心信号为 AxPROT[1]：

  • AxPROT[1] = 0：表示安全访问（Secure Access）

  • AxPROT[1] = 1：表示非安全访问（Non-Secure Access）

无论发起者是 CPU 还是 DMA，AXI 总线互联矩阵均会携带此硬件信号，将其透传至目标外设。

3. 接收端 (Slave)：访问权限拦截

当带有 AxPROT 标记的请求抵达目标之前，需经过硬件检查器的最终校验：

  • 内存（SRAM/Flash/DRAM）：由 MPC（Memory Protection Controller）守护。MPC 内部记录各段物理内存的安全属性划分，若非安全请求尝试访问被标记为安全的内存块，MPC 将在硬件层面直接拦截访问并报错。

  • 普通外设（Peripherals）：由 PPC（Peripheral Protection Controller）守护，控制某个外设（如某组 UART 或 SPI）是否仅限安全世界访问。

  • 自带安全鉴权的外设：部分 IP 自身硬件具备解析 AxPROT 信号的能力，无需外挂 PPC，可在其内部寄存器级别实现细粒度的安全控制。

系统启动与安全锁定

为确保上述硬件检查器（MPC/PPC 等）的配置不被恶意篡改，Ameba 采用严格的安全启动与锁定流程。

启动时序

  1. Secure CPU 率先唤醒：芯片上电或复位后，具备最高权限的 Secure CPU（KM4TZ）率先启动，此时系统处于 Secure World。

  2. 初始化安全边界：运行于 KM4TZ 的 Bootloader（image1）读取开发者预设的配置，初始化 SAU，并配置全系统的 MPC 和 PPC，完成安全边界的划分。

  3. 执行配置锁定（Lock）：所有安全边界划分完毕后，KM4TZ 执行锁定操作。

锁定机制

锁定操作指向安全控制硬件（如 MPC 的 IDAU_LOCK 或 PPC 的 PPC_LOCK）的特定寄存器写入锁定标志位。一旦执行锁定：

  • 该硬件组件的所有安全配置寄存器将被物理冻结。

  • 不仅 Non-Secure World 无法修改配置，即使 Secure World 的 KM4TZ 也无法再进行修改。

  • 唯一的解锁途径是对系统进行硬件级复位（Reset）。

在 Ameba SDK 的默认实现中，Bootloader（image1）配置 MPC 和 PPC 时会锁定 MPC，而 PPC 保持未锁定状态。 这意味着 MPC 的内存安全划分在启动后不可更改，而 PPC 的外设归属配置可在运行时由安全固件动态调整。

架构特点

基于上述硬件隔离机制与启动锁定流程，Ameba SoC 依托 Arm TrustZone 技术建立的 SPE 安全处理环境具备以下特点：

  • 硬件隔离：隔离机制深植于芯片物理层，所有访问拦截均由底层硬件控制器直接裁决。

  • 零性能损耗：硬件级别的安全属性校验与实际数据地址传输并行处理。开启 TrustZone 保护并拦截非法访问几乎不增加系统总线延迟，实现高安全性与高性能兼顾。

  • 配置灵活：系统并未在出厂时固定所有内存和外设安全边界。开发者可以根据产品业务需求调整安全与非安全内存大小，并自由定义每个外设节点的安全属性，适配多样化的应用场景。

备注