ARM Cortex-M
Privileged/Non-Privileged Vs Secure/NonSecure.
SITE HOME
Scope:
This
techerature compares the Privileged/Non-Privileged
operation Vs Secure/Non-Secure
operation in ARM Cortex-M processors. Of course this will be
applicable to only those Cortex-M which support Secure/Non-Secure.
e.g. ARM Cortex-M23, ARM Cortex-M33, ARM Cortex-M55.
There are fundamental differences between
Privileged/non-privileged operation and Secure/Non-Secure
operation.
Note the use of 'operation' I have deliberately not used 'mode' or
'state', as you will realize that using the word 'mode' or 'state'
with secure/non-secure or privileged/non-privileged won't be
appropriate, as I will explain in this techerature.
Though the ARM's document do use the words 'state' e.g. secure-state
or non-secure state, however I believe that they are a bit
in-appropriate.
Immediately after reset, all the accesses the processor generates
are deemed to be
- Privileged accesses
- Secured accesses.
This means:
- All the AHB accesses will have their HPROT[1] bit = '1'
indicating that the access is privileged, all AXI accesses will
have their AxPROT[0] bit = '1' indicating the access is
privileged.
- All the AHB accesses, will have their HNONSEC bit = '0'
indicating that the access is secured, all AXI accesses will
have their AxPROT[1] bit = '0', indicating the access is
secured.
'State' or 'mode' of the processor immediately after reset.
Privileged/Non-Privileged Operation:
Out of reset, the processor will be in privileged state or
privileged mode, whatever you may want to call it. Use of
'state' or 'mode' can be appropriate while addressing the
privileged/non-privileged distinction, because the way the processor
can switch between the two distinct operation arrangements.
The user i.e. the software can write to a special register within
the system control register space to explicitly change the
processor's operating mode/state from 'privileged' to
'non-privileged'. But once this bit has been written to make the
switch to non-privileged mode/state, then whatever software is now
running cannot write to this register. So, there is a defined
'state'/'mode' of the processor which the user can change while the
processor is in privileged state by writing to a defined register.
Hence forth the processor changes its 'state'. The accesses coming
out of the processor now will indicate the 'state'/'mode' of the
processor using HPROT, AxPROT.
Also note that this processes so far is totally in-dependent of the
Memory Protection Unit of the processor. The
Privileged/Non-Privileged Operation distinction can be done
without using MPU.
Secure/Non-Secure Operation:
However the secure/non-secure isn't dealt in the same way. There is
no register to be written to switch the processors 'state'/'mode'
Hence using these in secure/non-secure context is bit fizzy.
Immediately after reset all accesses are 'secured' as indicated by
HNONSEC and/or AxPROT[1].
The user will then program the SAU (The security attribution Unit)
to partition the system memory map into 'secure', 'non-secure' and
'secure-calleable' regions. If the SAU is not programmed, (and the
IDAU is not being used), all access remain 'secure'.
Following the SAU programming, the accesses from the processor are
still 'secure' accesses, unless the software then uses one of the
special prescribed instructions e.g. BLXNS or BXNS to make 'jump' to
a location that has been marked as 'non-secured' while programming
the SAU. All the code that now runs following this 'jump' using
these special instructions are now deemed to be 'non-secure', and
all the accesses will now have their HNONSEC = '1' for AHB and
AxPROT[1] = '1' for AXI indicating that the accesses are
'non-secured'.
Note: The partitioning of the memory map
can either be done by SAU using software, or can be done by HW
IDAU unit, it has the same effect. And if any location is marked
as 'secure' either by SAU or by IDAU, its always deemed to be
'secure'.
Notice that the SAU programming (or IDAU HW) is necessary for the
processor to determine an access level of its transactions. So the
secure/non-secure isn't actually a 'state' or 'mode' it just how a
transaction is deemed by the SAU/IDAU.
Now if any code running following a BLXNS or BXNS assisted change of
access levels to non-secure, tries to access a memory location
within a region that has been marked as 'secure' by the SAU or the
IDAU, the processor generates a fault.
This also means that when a code is running with secured access
level, it can access all the memory map, and for all accesses the
signal HNONSEC/AxPROT will indicate that it is a secured access,
even if the code tries to access a location marked as 'non-secure'
by the SAU/IDAU.
Notice the diff between priv/non-priv and secure/non-secure.
For priv/non-priv there isn't any memory map allocation done. You
write to a register and the processor switches its state/mode from
priv to non-prive.
For secure/non-secure the memory map must be allocated
secure/non-secure/secure-calleable regions using the SAU or the
IDAU. Then the processor must execute a special instruction (BLXNS
or BXNS), to jump to a non-secure region a defined by the SAU/IDAU
to switch its access from Secure to Non-Secure.
This difference also means that
The system is protected by SAU/IDAU at the source for any accesses
violation. An access violation here means when a code which has been
put in a location which has been defined by SAU/IDAU as insecure
tries to access a region of memory that has been defined as secure
by SAU/IDAU.
That is to say, that a non-secure code cannot have its transaction
with HNONSEC = '0' (or AxPROT[1]='0', i.e. indicating that it is a
secured transaction).
While in case of priv/non-priv, the non-priv code can still indicate
that it has priv rights, if the program fails to switch the
'state'/'mode' of the processor (by writing to a system control
register), before it goes on to execute non-priv code.
Conclusion:
While the priv/non-priv operation of the processor does not depend
upon any memory-allocations, the secure/non-secure operation of the
processor does depend upon the allocation of regions of secure and
non-secure memory.
While the priv/non-priv are clearly 2 'states'/'modes' the processor
can be in, and the switching from priv to non-priv is as simple as
writing to a system register, the secure/non-secure differentiation
isn't that straightforward. Hence I dont associate the terms 'state'
or 'mode' while addressing secure/non-secure operation. Though the
ARM document makes use of secure-non-secure 'state'. The
secure/non-secure operation is determined if the code running on the
processor is being fetched from a secure or a non-secure memory
location as defined by the SAU/IDAU.
<=
PREV : ARM User/Privilege Levels Next => ARM
Cortex-M TrustZone
Click Here to Make Comments or ask Questions
SITE HOME