Introduction to ARM
This techerature introduces the TrustZone on ARM Cortex-M
To understand ARM's TrustZone, you may want to visit ARM's
User/Privilege Levels Page.
Certain ARM-Cortex-M processors e.g. M33 or M23, implements the ARM
v8.Main Instruction set Architecture. One of the main features of
the ARM v8 Instruction Set Architecture is enhanced security using
what ARM calls as 'TrustZone' Technology.
The Classification of Privileged/Non-Privileged 'Access Level'
provides some basic form of security mechanism, which the users may
use to implement access rights of software running on the processor
on system's memory space.
However the Privilege Level classification had one shortcomings.
The Handler mode always had 'Privileged' level of access. This meant
that if the user wants to write an application, then they cannot
normally write interrupt service routines, as ISRs can only run in
'Privileged' access levels, and as a system designer you may not
want to give 'Privileged' access level to normal user software,
which can easily be un-trusted.
However there are workarounds. E.g. the 'handlers' can be made to
run in 'unprivileged' level, by using a software wrapper around
them. This wrapper will protect the system memory from this handler.
This is typically done through MPU programming.
But then each time this un-trusted handler would run, the MPU will
It is clear that may be a mechanism that would allow the users to
write ISRs is needed.
Arm TrustZone on Cortex-M is a solution to the above problem. It
introduces another 'Level' of Access rights, which is called
'Secure/Non-Secure'. This is also at times called
Now the processor can have 4 Levels of Access.
In ARM's words, the TrustZone feature adds two processor 'states',
- Non-Secure, Unprivileged
- Secure, Unprivileged
- Non-Secure, Privileged
- Secure, Privileged.
A new signal which will indicate Secure/Non-Secure was then
For AXI, this signal is already there. AxPROT.
But then what ARM Cortex-M has AXI interface and implements ARM's
TrustZone? None-at the moment (Dec 2019), but something might be
For AHB, this signal is called HNONSEC. When HNONSEC = '1', the
transfer is Not-Secure. Tie this signal to '1', if TrustZone support
is NOT required.
The AHB protocol up to AMBA4 does not support this signal. Hence to
support ARM's TrustZone technology on AHB, AMBA 5 AHB is required or
alternative custom HW design will be required to add this signal as
an extra bit on AMBA 4 AHB or earlier versions of AHB protocol.
TrustZone allows the user to have two different access levels on
while the processor is in 'Handler Mode' i.e. Secure, Non-Secure.
This allows the users to write Interrupt Service Routines (ISRs),
which has limited 'access rights', thereby protecting critical
memory regions, which the software written for processors like M3/M4
without ARM's TZ cannot normally do.
All of the above theory means, that form HW point of view, and for
the system designer designing the system around the processor with
TrustZone support, its only 1 bit of signal i.e. HNONSEC Or
AxPORT, is important.
Now looking from the point of view of the Processor itself, the
processor has to implement a method which the software will exploit
to make the switch between this newly introduced Secure/Non-Secure
For this the processor now has
Looking from the point of view of the programmer, i.e form the
Software point of view, the TrustZone requires the following the
memory to be partitioned such that it now has the following 3 memory
To partition the memory space into the 3 above said regions, the
processor has SAU (Security Attribution Unit). Its in a way similar
to the MPU (Memory Protection Unit).
- Secure Region
- Non-Secure Region
- Non-Secure Callable region.
The above said 'Secure Region' and 'Non-Secure' regions are very
intuitive to understand, and they are what they sound like. But the
3rd region called 'Non-Secure Callable' requires some explanation.
But first its important to understand how the processor switches
from Secure-Non-Secure and vice-versa.
Before the processor makes a switch, obviously the programmer will
partition the memory space into 'secure' and 'non-secure' regions.
This is done by programming the SAU. Taking a very simple example,
the user may just partition the entire memory space into 8 Secure
and 8 Non-Secure regions.
Upon reset, the processor's access Level is 'Secure' if the
TrustZone is opted in, while configuring the processor.
This means that HNONSEC signal will be '0', and if there is an AXI
I/F then AxPROT will be '0' for any instructions that are
executed from Reset, till the point an explicit change of
processor's state has been done from Secure to Non-Secure.
There is also a signal on the processor called 'CURNS' which
indicates the processor's Access Level.
CURRNS = '0' => means Secure
CURRNS = '1' => means Non-Secure.
Switching from Secure to Non-Secure:
The ARM v8.Main then provides instructions BLXNS and BLNX which can
be used by Software to make a switch from Secure to Non-Secure
Switching form Non-Secure to Secure:
This involves the code running with Non-Secure Access level to
execute 'SG' instruction. SG=SecureGateway. The
SG instruction must always be placed into memory region defined
as 'Non-Secure Calleable'. And this is why this
'Non-Secure Calleable Region' definition is needed while
partitioning the memory regions. This is the only memory region the
Non-Secure code can branch out to, apart from of course any other
Again form Software point of veiw, the software architecture will
now need to define for all the images, if they will be kept at
'Secure' Or 'Non-Secure' Regions. This can be done via using linker
options or via using Scatter-Load
Behind the Scene:
When the Secure-to-NonSecure Switch instruction is executed e.g.
BLXNS,(which would change the processor's State to Non-Secure form
Secure), the context of the processor is stored in 'secure-stack'
which is pointed to by the Secure Stack pointer.
Likewise when the Non-Secure-to-Secure Switch instruction is
executed (SG), the context of the processor is stored in
'non-secure' stack which is pointed to by the Non-Secure Stack
pointer. However it is to be noted that this context save is not an
automatic process. Not at least if you are writing assembly code.
However while writing C-Code, ARM provides some functions, which
when called form C-Code will produce all he assembly code to switch
the processors' Security state, and save the processor's context at
The ARM Cortex-M TrustZone is nothing but an addition of a
secure/non secure signal, to indicate Secure/Non-Secure Processor
State. In addition to already existing Privileged/User Access
Levels, the user now has 4 Access levels using all possible
combinations of Secure, Non-Secure, Privileged and Non-Privileged.
Software point of view, things are far more complex, as it is
evident form ARM's documentation here.
If you are after some C/Assembly code for ARM
TZ, Click Here: This is an example full code to make a processor
state switch from Secure to Non-Secure World.
PREV : ARM User/Privilege Levels
Next => ARM
Click Here to Make Comments or ask Questions