The intention of this article is to give a guide to what issues need to be considered when setting up the memory space of a v8-M system for use in secure and non-secure applications.
We will use the SSE-200 subsystem here for the sake of example, but the information can be used for any similar Armv8-M systems.
Armv8-M processors have two mechanisms that define the security state of blocks of memory. They also control the security state of memory accesses that are issued from the processor.
The Armv8-M architecture defines three security attributes for memory that are used internally by the processor:
Secure
Used for Secure code and data
Non-secure
Used for Non-secure code and data
Secure and Non-secure callable
Used to contain Secure veneers or trampoline code that allows Non-secure code to safely call Secure functions
Once memory accesses are issued on the bus (for example using the AHB-5 protocol) accesses will have either the Secure or Non-secure attribute.
IDAU
The Implementation Defined Attribution Unit (IDAU) is a system specific unit that controls access to secure and non-secure memory. The IDAU maps memory blocks into Secure and Non-Secure regions.
For example, in SSE- 200 the software sees the memory blocks mapped as follows:
From the software perspective, each block has two, non-contiguous memory regions available, one secure and one non-secure. Physically there is actually a single block of physical memory, and the security system makes one part of the block available to secure code at address X and the other part of the block available to non-secure code at address Y. The IDAU region boundaries are fixed by hardware and are not configurable. The security attribute of some regions can be configured to either Secure or Secure and Non-secure callable using the NSCCFG Secure Privilege Control Register. The other IDAU regions have a fixed security attribute.
SAU
Security enabled Armv8-M systems will generally also contain a Secure Attribute Unit (SAU) which can be configured by the software. The security attribution performed by the IDAU and SAU are combined with the most secure attribute for an address becoming the effective security. The SAU will influence how the security attributes of an address are derived, even if it’s disabled.
In SSE-200, on reset SAU_CTRL is 0x0:
When the SAU is disabled and the ALLNS value is 0x0, as is the case after reset, all the memory is marked as Secure by the SAU. Combined with the default IDAU configuration, this marks *every address* as Secure.
When ALLNS is 0x1 the whole memory is marked by the SAU as Non-Secure. When deriving the security attributes of an address, the IDAU configuration will always be “stronger”, so the final security attributes will be matching the layout defined by the IDAU.
When the SAU is enabled, rules are different: in particular if the SAU is enabled and an address is not part of any specified configured region of the SAU (i.e. memory ranges not covered by any configured region), it will always be regarded as Secure. The table below shows how the final security settings for a region depend on the settings in both the IDAU and SAU (X = Don't Care):
If the security attribute as determined by the combined SAU/IDAU configuration doesn’t match that allowed by the processor’s security state, the memory access will not be issued on the bus and the processor will take an internal exception.
MPC
Secure systems such as the SSE-200 also provides a Memory Protection Controller (MPC). The SIE-200 MPC component can affect memory and IO security management and must be configured as required for your application. On reset the MPC in a system will generally set all regions to secure, in which case it will be necessary to set the MPC as required.
The IDAU and SAU affect the output from the processor to the bus, whereas the MPC affects the accesses from the bus to the memory. The SAU and IDAU steps are in parallel, they are effectively one step, and are followed by the MPC.
Non-secure code can run only if all three devices (IDAU, SAU, MPC) are configured as non-secure for the code SRAM address.
NOTE: The IDAU/SAU defines regions which can be configured to be Secure Non-Secure Callable (S-NSC), based on the NSCCFG Secure Privilege Control Register. When writing Secure/Non-Secure applications, compilation tools will need to be configured (i.e. via scatter file) to place all S-NSC veneers in S-NSC memory regions.