You copied the Doc URL to your clipboard.

The TrustZone hardware architecture

The TrustZone architecture provides a means for system designers to help secure systems, using the TrustZone Security Extensions, and Secure peripherals. Low-level programmers should understand the design requirements that are placed on the system by the TrustZone architecture, even if they do not use the security features.

The ARM Security Extensions model allows system developers to partition device hardware and software resources, so that they exist in either the Secure world for the security subsystem, or the Normal world for everything else. Correct system design can ensure that no Secure world assets can be accessed from the Normal world. A Secure design places all sensitive resources in the Secure world, and ideally has robust software running that can protect assets against a wide range of possible software attacks.

security_model.png

The ARM Architecture Reference Manual uses the terms Secure and Non-secure to refer to system security states. A Non-secure state does not automatically mean security vulnerability, but rather normal operation and is therefore the same as the Normal world. Typically, there is a master and slave relationship between Non-secure and Secure worlds. Code in the Secure world is only executed when the OS permits Secure world execution through a mechanism that is initiated by the Secure Monitor Call (SMC) instruction.

Note

The use of the word world is used to describe not just the Execution state, but also all memory and peripherals that are accessible in that state. Non-secure memory and functions are also accessible to the Secure world.

The role of the Secure monitor is to provide a gatekeeper which manages the switches between the Secure and Non-secure worlds. In most designs its functionality is similar to a traditional operating system context switch, ensuring that state of the world that the core is leaving is safely saved, and the state of the world the processor is switching to is correctly restored.

The additions to the architecture mean that a single physical core can execute code from both the Normal world and the Secure world, each world can yield to or call the other, although this depends on the availability of interrupt-generating peripherals that can be configured to be accessible only by the Secure world. For example, a Secure timer interrupt could be used to guarantee some execution time for the Secure world. Such peripherals might be available, depending on the level of security and use cases that the platform designer intends to support.

The Secure monitor is a security critical component, as it provides the interface between the two worlds. For robustness reasons, that the monitor code should execute with interrupts disabled. Writing a reentrant monitor would add complexity and is unlikely to provide significant benefits over a simpler design.

Alternatively, an execution model closer to cooperative multitasking can be used. Although the Secure world is independent of the Normal world in terms of the resources each world can access, each world can yield to the other to enable code execution.

Like firmware or any other piece of system software, software in the Secure world must minimize its impact on other parts of the system. For example, consumption of significant execution time should usually be avoided unless performing some action requested by and expected by the Normal world. Non-secure interrupts should be passed to the Normal world as quickly as possible. This helps to ensure good performance and responsiveness of Normal world software without the need for extensive porting.

The memory system is divided by an extra bit that accompanies the physical address of peripherals and memory. This bit, called the NS-bit, indicates whether the access is Secure or Non-secure. This bit is added to all memory system transactions, including cache tags and access to system memory and peripherals. The NS bit can give a different physical address space for the Secure and the Normal worlds.

Software running in the Normal world can only make Non-secure accesses to memory, because the core always sets the NS bit to 1 in any memory transaction that is generated by the Normal world, irrespective of what is set in the Normal world translation tables. Software running in the Secure world usually makes only Secure memory accesses, but can also make Non-secure accesses for specific memory mappings using the NS and NSTable flags in its translation table entries.

Trying to perform a Non-secure access to cached data that is marked as Secure causes a cache miss. Trying to perform a Non-secure access to external memory marked as Secure will generally return an error response to the core. There is no indication to the Non-secure system that the error is caused by an attempted access to Secure memory.

EL3 has its own translation tables, which are governed by the Translation Table Base Register TTBR0_EL3 and the Translation Control Register TCR_EL3. Only stage one translations are allowed in the Secure world and there is no TTBR1_EL3. The EL1 translation table registers are not banked between security states and therefore the value of TTBR0_EL1, TTBR1_EL1, and TCR_EL1 must be saved and restored for each world as part of the context switching operation by the Secure Monitor.

This enables each world to have a local set of translation tables, with the Secure world mappings hidden and protected from the Normal world. Entries in the Secure world translation tables contain NS and NSTable attribute bits that determine whether particular accesses can access the Secure or Non-secure physical address space.

Secure and Non-secure entries can co-exist within the caches and TLBs. There is no need to invalidate cache data when switching between worlds. The Normal world can only generate Non-secure accesses, so can only hit on cache lines marked as Non-secure, whereas the Secure world can generate both Secure and Non-secure accesses. This may require some cache management if the security state is changed between accesses, this may require some cache management if the security state is changed between accesses.

Entries in the TLB record which world generates a particular entry, and although the Non-secure state can never operate on Secure data, the Secure world can allocate NS lines into the cache. Also, the caches are enabled and disabled separately for each of the Exception levels. Cache control is independent for the two worlds, but is not independent for all Exception levels, so EL0 can never enable or disable the caches directly, and EL2 can override behavior for Non-secure EL1.

Was this page helpful? Yes No