2.3.10. TrustZone technology and security

This section applies if you are building a system based on the secure and non-secure capabilities that TrustZone technology provides. If the system does not require security using TrustZone technology, configure all master interfaces to be non-secure.

This section contains the following subsections:

TrustZone scope

The security checks that TrustZone technology implements cover the scope of a configured network.


TrustZone is a brand name that represents aspects of implementing ARM Security Extensions.

For example, security checks that are not within the scope of the network are:

Physical attack

Physical attack on the device.

Non-TrustZone-aware masters being made secure

A master might require access to the Global Programmers View (GPV) and in this case, you can tie the security transaction indicator bits so that all accesses by that master are indicated as secure. This places that master permanently in the secure domain. However, depending on the other usage of that master, this might mean that the overall system is not as secure under all circumstances.

System implementation information

If you do not consider all the masters that have access to the GPV, this can produce security vulnerabilities. For example:

  • If a non-secure state master can set QoS requirements effecting its non-secure transactions, then that non-secure state master can use this capability, in conjunction with traffic analysis, to determine the QoS and priority settings of a secure master. This can be a threat in particular implementations.

  • A TrustZone-aware slave requires you to set the connecting network as non-secure so that the network does not filter the secure traffic and leaves the slave to determine the correct response. Consider the master that can make this non-secure configuration against and the master, or masters, that can program the TrustZone-aware slave.

Topology issues

It might be possible to suffer timing attacks because of the topology configuration you chose. For example, if two cascaded switches exist with a shared AXI link between them, then continuous non-secure accesses to a non-secure slave might block secure transactions to a different secure slave.


It might be possible to carry out a secure attack by resetting only parts of a data path, whether it be a data path section in an individual clock domain within a network, or within a master or slave.

Hierarchical clock-gating

It might be possible to carry out a denial of service attack by gating clock domains. Only masters in the secure domain must access the clock controller.

Slave interface security

At configuration time, each slave interface, whether it belongs to the AXI or AHB protocol, has the following options for setting the security assignment of all its transactions:

  • input from the external master, for AXI masters only

  • tied-off to always issue transactions as secure

  • tied-off to always issue transactions as non-secure.

Internal programmers view

The programmers view is always secure access only. Any non-secure transaction intended to access a register, input to a configuration, returns a DECERR, and no register access is provided.


If you configure a dedicated configuration port to gain access to the GPV, then you must connect it to a secure master, or have a security check that is external to the CoreLink NIC-400 Network Interconnect.

Security checking for master interfaces

You can configure each master interface to be:

Always secure

The master rejects non-secure transactions.

Always non-secure

The master accepts both secure and non-secure transactions.

Boot secure

You can use software to configure whether it permits secure and non-secure transactions to access components attached to this master using the Always secure and Always non-secure options above.


  • If you change the security of a master interface, the change does not occur simultaneously for all the masters in the system because of the distributed nature of the GPV.

  • Outstanding transactions, or active lock sequences, underway within the network at the time of the security update use the old security settings for their security check.

For an APB master interface, where multiple slaves exist on a single interface, each APB slave has its own security check.

If an incoming transaction is non-secure, either because the slave interface is configured to be non-secure, or the input security bit is set be non-secure, then if that transaction is intended for a master interface that is currently secure, then that transaction is returned with a DECERR, and the transaction is not transferred to the slave.

All accesses must be secure to gain access to any programmers model register. Any non-secure accesses to the programmers model receive a DECERR response. See Chapter 3 Programmers Model.

Security registers are not updated if a pending transaction exists, or if a current ongoing lock sequence exists.

Copyright © 2012 ARM. All rights reserved.ARM DDI 0475A