ARM Cortex-M Privileged/Non-Privileged Vs Secure/NonSecure.
-Aviral Mittal avimit att yahu dat cam.

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
  1. Privileged accesses
  2. Secured accesses.

This means:

'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.

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