TrustZone technology [2.7] refers to the security extensions introduced with ARMv6K in all ARM Cortex-A processors. The TrustZone hardware architecture can be seen as a dual-virtual system, partitioning all system’s physical resources into two iso- lated execution environments (Figure 2.1a). Recently, ARM also decided to extend TrustZone for the Cortex-M processor family [2.8]. TrustZone for ARMv8-M has the same high-level features as TrustZone for applications processors, with the benefit that context-switching between both worlds is done in hardware for faster transi- tions. In the remainder of this Section, when describing TrustZone, I am focused on the specificities of this technology for Cortex-A processors. The distinctive aspects of TrustZone for ARMv8-M are out of the scope of this thesis.
Flash Flash Flash CPU Non-Secure Peripherals
SRAM PeripheralsSecure
Flash
AMBA Interconnect
Secure World Non-Secure World
DMA
(a) TrustZone hardware architecture
Secure World Non-Secure World Monitor Secure Kernel OS Secure Services Normal OS Client
Applications User Mode
Privileged Modes
Monitor Mode
(b) TrustZone software architecture
2.3.1
TrustZone: Hardware Component
At the processor level, the most significant architectural change is its partition into
two separate worlds: the secure and the non-secure worlds. A new 33rd processor
bit, the NS bit, accessible through the Secure Configuration Register, indicates in which world the processor is currently executing, and is propagated over the memory and peripherals buses. To preserve the processor state during the world switch, TrustZone adds an extra processor mode: the monitor mode. The monitor mode is completely different from other supported modes, because when the processor runs in this mode the state is always considered secure, independently of the NS bit state. Software stacks in the two worlds can be bridged via a new privileged instruction - Secure Monitor Call (SMC ). The monitor mode can also be entered by configuring it to handle IRQ, FIQ and Aborts exceptions in the secure world. To guarantee a strong isolation between secure and non-secure states, some special registers are banked, such as several System Control Coprocessor (CP15 ) registers. Some secure critical processor core bits and CP15 registers are either totally unavailable to non- secure world or access permissions are closely under supervision of the secure world. To provide the exception behavior described above, TrustZone specifies three sets of exception vector tables - one for the non-secure world, one for the secure world, and another for the monitor mode.
The TrustZone Address Space Controller (TZASC) extends TrustZone security to the memory infrastructure. The TZASC can partition the off-chip RAM (DRAM) into different memory regions: this hardware controller has a programming interface, accessible only from the secure side, that can be used to configure a specific memory region as secure or non-secure. By default, secure world applications can access non- secure world memory but the reverse is not possible. The number of memory regions, and the bus widths of the TZASC interfaces, are configurable when the design is synthesized by each vendor. The TrustZone Memory Adapter (TZMA) provides similar functionality but for on-chip memory. This means it enables a design to secure a region within an on-chip static memory such as a ROM or an SRAM. The TZMA allows a single static memory of up to 2MB to be partitioned into two regions, where the lower part is secure, and the upper part non-secure. The location of the partition between the secure and non-secure regions is always a multiple of 4KB. The TZMA cannot be used for partitioning dynamic memories, or memories that require more than one secure region. In this specific case, the TZASC must be used. The TrustZone-aware MMU provides two distinct MMU interfaces, enabling each
world to have a local set of virtual-to-physical memory address translation tables. The isolation is still available at the cache-level, because processor’s caches have been extended with an additional tag bit which signals in which state the processor accesses the memory.
System devices can be dynamically configured as secure or non-secure through the TrustZone Protection Controller (TZPC). The TZPC is a configurable signal con- trol block which can be placed on the Advanced Peripheral Bus (APB) to supply control signals to other components on the SoC. The direct memory access (DMA) controller is a dedicated engine used for moving data around the physical memory system, instead of using the processor to perform this task. The DMA can support concurrent secure and non-secure channels, each with independent interrupt events and controlled by a dedicated APB interface. A non-secure transaction trying to program a DMA transfer to or from secure memory will result in the DMA transfer failing.
To support the robust management of secure and non-secure interrupts, the Generic Interrupt Controller (GIC) provides both secure and non-secure prioritized interrupt sources. An interrupt can be configured as a secure interrupt through the Interrupt Security Register. In addition, the interrupt controller supports interrupt prioritiza- tion, allowing the configuration of secure interrupts with a higher priority than the non-secure interrupts. Such configurability prevents non-secure software to perform a denial-of-service attack against the secure side. The GIC also supports several interrupt models, allowing for the configuration of IRQs and FIQs as secure or non- secure interrupt sources. The suggested model by ARM proposes the use of IRQs as non-secure world interrupt sources, and FIQs as secure interrupt sources.
2.3.2
TrustZone: Software Component
There are many possible software architectures which a software stack on a TrustZone- enabled processor core could implement. Figure 2.1b depicts the generic software ar- chitecture, where software components are distributed between both worlds. Adopt- ing a bottom-up description, the software running in the secure world is composed by the Monitor layer, the secure kernel and its corresponding service tasks. The Monitor component, running in Monitor mode, provides a robust gatekeeper which manages the switches between the Secure and Non-secure processor states. The secure ker- nel, running in privileged mode, provides facilities for the concurrent execution of multiple independent secure services (running in a non-privileged mode). The soft-
ware running in the non-secure world side, in turn, consists of a general-purpose operating system with the corresponding TrustZone API-dependent software and the client applications.
The TrustZone API (TZAPI) [2.9] is an application programming interface which specifies how normal applications running on the rich OS interact with the iso- lated execution environment. Basically, following a client-server model, the API defines a set of abstract software interfaces through which non-secure client appli- cations (NSCApps) can interact with the secure services. The API allows clients to send commands and requests to a secure service, and exchanges data between both worlds. Secondary features of the API allow, for example, to query the properties of installed services as well as download new security services at run-time. The (publicly available) TrustZone API does not include any specification about how to develop applications running inside the isolated execution environment. Hence, while it could be useful for application developers, by itself it does not fully specify the APIs needed for developing secure services.