Overview

Ameba SoC employs Arm TrustZone technology to implement hardware-level security isolation, establishing an SPE (Secure Processing Environment) within the chip. Through the TrustZone mechanism, the system physically isolates secure firmware from normal applications at the hardware level. Once the TrustZone protection mechanism is enabled and locked, even if code in the non-secure environment obtains the highest system execution privilege, it cannot bypass the underlying hardware restrictions to steal or tamper with secure resources.

Key Concepts

Before diving into the underlying hardware mechanisms, developers should first understand the following firmware classification concepts at the software level and their correspondence within the Ameba heterogeneous multi-core architecture:

Heterogeneous Multi-Core Architecture: Different processor cores (Masters) have different physical security attributes:

  • Secure CPU (e.g., KM4TZ, CA32): Equipped with full TrustZone hardware extensions, capable of dynamically switching between Secure World and Non-Secure World, and responsible for managing system security policies.

  • Non-Secure CPU (e.g., KM4NS, KM0, KR4, DSP): Lacks security extensions, is hardware-fixed to operate in Non-Secure state, and all bus access requests it issues carry a “non-secure” label by default.

Firmware Classification: In the Ameba SDK, system firmware is divided into two isolated domains:

  • Secure Firmware: Runs in the Secure World and can access all system resources (including both secure and non-secure resources). It is primarily responsible for managing core keys, performing cryptographic operations, secure boot verification, and configuring system security boundaries. Secure firmware consists of two parts: image1 and image3. image1 is the Bootloader for the KM4TZ core, executing firmware loading and verification in Secure mode; image3 is an independent secure firmware providing security services. Both run in the Secure World.

  • Normal Firmware: Known as image2 in the Ameba SDK, it runs in the Non-Secure World and can only access memory and peripherals classified as non-secure, or request security services from the secure world through dedicated NSC (Non-Secure Callable) interfaces. The regular RTOS, network protocol stacks, and business logic all run in this domain.

RDP Read Protection: To further enhance the security of image3 (secure firmware), Ameba introduces the RDP (Read Protection) mechanism. TrustZone provides runtime isolation, while RDP ensures static storage security:

  • Encrypted firmware storage: Secure firmware is stored in Flash in encrypted form and is automatically decrypted by hardware at runtime for execution.

  • Physical read protection: Even if an attacker gains physical access to the Flash chip, they cannot directly read the plaintext content of the secure firmware.

  • Firmware clone prevention: The encrypted firmware is bound to the chip’s internal OTP key, preventing the firmware from being copied to another chip for execution.

Hardware Isolation Mechanism

Arm TrustZone establishes a complete hardware protection chain by deploying interception mechanisms at three core nodes along the system bus: the initiator, the transport, and the receiver:

../../_images/trustzone_bus_arch.svg

1. Initiator (Master): Security State Determination

All masters and slaves in the system are connected to the AXI bus. When a Master initiates a memory or peripheral access, its security attribute is determined as follows:

  • CPU Masters (e.g., KM4TZ): Based on the current CPU operating state (Secure or Non-Secure), combined with its internal IDAU (hardwired security address mapping) and SAU (software-configurable Security Attribution Unit), the corresponding security label is automatically applied to the access.

  • Masters without security extensions (e.g., KR4, DSP): These masters are hardware-fixed to operate in Non-Secure state, and all bus access requests they issue carry a “non-secure” label by default. They cannot issue Secure requests.

  • Masters with security extensions (e.g., GDMA, Crypto Engine, and other IPs): These peripherals do not have an SAU unit, and their security attributes depend entirely on dedicated configuration registers. To issue Secure requests, the Secure CPU (KM4TZ) must pre-configure their security control registers to grant Secure permission. Otherwise, all bus requests from these devices are Non-Secure requests.

2. Transport (Bus): Security Attribute Propagation

The AXI bus protocol includes dedicated standard signal bits for conveying the privilege and security attributes of an access. The core signal is AxPROT[1]:

  • AxPROT[1] = 0: Indicates Secure Access

  • AxPROT[1] = 1: Indicates Non-Secure Access

Regardless of whether the initiator is a CPU or DMA, the AXI bus interconnect matrix carries this hardware signal and transparently propagates it to the target peripheral.

3. Receiver (Slave): Access Permission Interception

Before a request carrying the AxPROT label reaches its target, it must pass through a final validation by hardware checkers:

  • Memory (SRAM/Flash/DRAM): Guarded by the MPC (Memory Protection Controller). The MPC internally records the security attribute classification of each physical memory segment. If a non-secure request attempts to access a memory block marked as secure, the MPC will intercept the access at the hardware level and report an error.

  • Peripherals: Guarded by the PPC (Peripheral Protection Controller), which controls whether a specific peripheral (e.g., a UART or SPI group) is restricted to the secure world only.

  • Peripherals with built-in security authentication: Some IPs have the hardware capability to parse AxPROT signals internally, without requiring an external PPC. They can implement fine-grained security control at the internal register level.

System Boot and Security Lockdown

To ensure that the configuration of the hardware checkers (MPC, PPC, etc.) cannot be maliciously tampered with, Ameba adopts a strict secure boot and lockdown process.

Boot Sequence

  1. Secure CPU wakes up first: After the chip powers on or resets, the Secure CPU (KM4TZ) with the highest privilege starts first. At this point, the system is in the Secure World.

  2. Initialize security boundaries: The Bootloader (image1) running on KM4TZ reads the developer’s preset configuration, initializes the SAU, and configures the system-wide MPC and PPC to complete the security boundary partitioning.

  3. Execute configuration lockdown (Lock): After all security boundaries are set, KM4TZ executes the lockdown operation.

Lockdown Mechanism

The lockdown operation writes a lock flag to specific registers of the security control hardware (such as MPC’s IDAU_LOCK or PPC’s PPC_LOCK). Once locked:

  • All security configuration registers of the hardware component are physically frozen.

  • Not only can the Non-Secure World not modify the configuration, but even the Secure World’s KM4TZ can no longer make changes.

  • The only way to unlock is through a hardware-level system Reset.

In the Ameba SDK’s default implementation, the Bootloader (image1) locks the MPC when configuring it, while the PPC remains unlocked. This means that the MPC’s memory security partitioning cannot be changed after boot, while the PPC’s peripheral ownership configuration can be dynamically adjusted at runtime by the secure firmware.

Architectural Characteristics

Based on the hardware isolation mechanism and boot lockdown process described above, the SPE established by Ameba SoC through Arm TrustZone technology has the following characteristics:

  • Hardware Isolation: The isolation mechanism is deeply embedded in the chip’s physical layer. All access interception is directly adjudicated by underlying hardware controllers.

  • Zero Performance Overhead: Hardware-level security attribute validation is processed in parallel with actual data address transfers. Enabling TrustZone protection and intercepting unauthorized access adds virtually no system bus latency, achieving both high security and high performance.

  • Flexible Configuration: The system does not fix all memory and peripheral security boundaries at the factory. Developers can adjust the size of secure and non-secure memory according to product requirements, and freely define the security attributes of each peripheral node to accommodate diverse application scenarios.

Note