Introduction to Cortex-M3/M4 M0+ Security (Privileged/Non-Privileged Access Level)
-Aviral Mittal avimit att yahu dat cam.

This techerature introduces the ARM's basic SoC Security Fundamentals. Its about the Privilege/Non-Privileged Access levels of Certain ARM Cortex-M processors, e.g. Cortex M0+, M3/M4.

To understand ARM's Privileged/User mode, you may want to visit Fundamentals of SoC Security Page.
ARM's offered scheme of Privileged/User mode is a way of implementing 'Access Control Mechanism' on the SoC's memory space.
In Previous sections we learned why and how it is important for a user to partition the SoC's memory space into sections, and apply different 'access rights' to different sections. In Summary, the 'trusted' software' may have permissions to access all the memory, and the 'untrusted' software only have 'limited' rights to access the sections of memory.

ARM's Privileged/User mode
This scheme allows the user to implement different 'Access Control' mechanisms to different sections of the memory. Instead of calling it as Privilege/User 'Mode', I would rather call it 'Privilege/User' 'Access level'. As the 'Mode' can be confused with 'Thread/Handler' Mode. The implementation of this scheme is based upon what 'mode' the processor is in. Certain ARM's Cortex-M processors (e.g. M0+, M3, M4,M7)  provides following two operating modes.
These modes are very simple to understand. Upon Reset, the processor starts in Thread mode. And as the name suggests, the processor enters 'Handler' mode when executing an exception handler such as an interrupt routine, following an interrupt assertion.
Then Certain Arm Cortex-M processor offers 2 'Access Levels', called

When the processor comes out of reset, it is in Handler Mode, and the access level is 'Privileged'.
"The processors' access level is Privileged" What does it actually mean?
This simply means that the accesses form the processor will have their signal HPROT[1] on AHB I/F = '1', and AxPROT[0] on AXI = '1',  indicating the access level of the access to be 'Privileged mode'. That's it.
Now it is up to the system designer to make use of this signal appropriately. The system designer typically will use this signal to allow access to certain memory regions in a controlled way. Hypothetically speaking, if the system is badly designed, and these signals are not used, then the Processors' Privileged Level scheme wont mean anything.
Hence in summary 'Privileged Level' is just an indication by the processor using a signal. Nothing else. The system-designer will then make use of it to design the system in a way which can use the signal indicating 'Privileged Level' to do certain things.
Straight out of reset, the Processor's access level is 'Privileged' mode. I.e. the accesses straight out of reset is supposed to have all the rights, but really its up to the system designer to make use of this level.

Relationship of Privileged/User Level with Thread/Handler Mode.

Thread/Handler mode is explained above. The processor's Privilege level is always 'Privileged' while in Handler mode, however when in 'Thread' Mode, the Processor's Privilege level can be Privileged or User (also called Non-Privileged Level). As said earlier, upon reset, the processor is in 'Thread' mode, with the Privilege level set to 'Privileged'.

Switching from Privileged Level to Un-Privileged Level:
The user can switch the Privilege Level of the processor by writing to Control Register bit 0. The Control Register is classified as a 'Special Core Register' which can be accessed by special Register Access Instruction MRS/MSR [MSR, CONTROL, r0]. Of course the control register is only accessible while the processor is operating in 'Privilege' Level i.e. the instructions MSR,MRS are not operational when the processor's Access Level is non-privileged (User). The reset value of this register is 0x0000_0000. This means bit [0] is '0' out of reset, which implies that the processor's Privilege Level is 'Privileged' straight out of the reset.

Switching from Un-Privileged Level to Privileged Level:

Once the processor has switched to the Un-privileged Access Level, the user cannot write to CONTROL reg. So, if the user wants to switch the Privilege level of the processor, SVC instruction may be used to do so.
SVC=Supervisor Call. Making a call to SVC function isn't a straight forward and the method to make this call is beyond the scope of this techerature.
SVC instruction is a soft exception call, and therefore following the SVC instruction, the processor will switch to 'handler' mode, and therefore to privileged level of access.
What happens next has 2 possibilities.
Note that the SVC instruction has a 8 bit encoded value with it, which is used as an index to call one of 256 possible different functions.

How does the user know if the Processor is operating in Privelege/User Access Level?

Quite simply the HPROT[1] on AHB accesses and AxPROT[0] on AXI accesses indicate the Privilege Levels. AxPROT = {AWPROT, ARPROT}.
Alternatively, the user may sample the value of CONTROL Reg using MSR/MRS instructions to know the Privilege Level of the Processor. But again it can only be done while the Privilege Level is actually 'Privileged'
The ways to detect the Processor's Access Level is very important. For a system designer, the signals HPROT[1], and AxPROT[0] are important, as the system designer will use these signals to determine the Processor's Access Level, and based upon this they may implement some control over how the system's memory space is accessed. However for a software programmer, its the CONTROL reg, which the user will read to know the Processor's Access Level.

For as long as the processor's 'Access Level' is Unprivileged (User), the access by the software within the processor is limited. e.g. The Processor's System/Control Register space cannot be accessed by the software running while the processor's access level is User (Unprivileged). Then certain instruction which act on special registers (Stack Pointer, CONTROL Reg), MRS/MSR are not available when the processor's access level is User(Unprivileged).
For outside the processor, its up to the system designer to implement the Access Control Mechanism based on HPROT[1] or AxPORT[0].

Typical use case of privileged/unprivileged level
In a typical embedded system, the OS kernel may run at privileged access level, having access to whatever it likes, with applications launched with unprivileged access level, with limited access rights. This can greatly help to make the embedded system robust and secure, as the application code will never be able to corrupt the system code. Usually MPU is used in conjunction with the privilege/unprivileged access levels to further restrict/control the user applications, and to enhance security. More about MPU use can be found here.

The Privilege Level of the processor is just a HW signal output i.e. HPROT[1] on AHB and AxPROT[0] on AXI. Then its up to the system designer to use this signal(s) to implement system memory access rights. However, it is to be noted that the the user may choose to use the MPU to implement far more fin grained 'access' rights to 'regions' of memory. Using MPU the user can do a lot more than just partition the memory into privilege/unprivileged levels. MPU is explained in this techerature.
This also sets the background on ARM Cortex-M TrustZone.

When the processor starts, i.e. is just out of reset, it must be executing trusted software/Firmware, as straight out of reset, the Processor's access level is 'Privileged', this means straight out of reset, the software/firmware has all the rights.

<= PREV  : Security Flow                                      Next => ARM Cortex-M Trust Zone

Click Here to Make Comments or ask Questions