ARM Cortex-M23 Secure World Access to Non-Secure Memory Fails
The ARM Cortex-M23 processor, part of the ARMv8-M architecture, introduces a security extension that divides the system into Secure and Non-Secure worlds. This separation is enforced by hardware mechanisms such as the Security Attribution Unit (SAU) and the Implementation Defined Attribution Unit (IDAU). When code running in the Secure world attempts to access memory or resources in the Non-Secure world, the processor must ensure that such accesses comply with the security rules defined by the SAU and IDAU. In this case, the issue arises when a Secure world application attempts to read Non-Secure memory using a simple LDR instruction. The processor unexpectedly jumps to address 0xEFFFFFFE, which is indicative of a SecureFault or an illegal memory access violation. This behavior suggests that the Secure world code is not properly configured or lacks the necessary permissions to access the Non-Secure memory region.
The Cortex-M23’s memory protection mechanisms are designed to prevent unauthorized access between Secure and Non-Secure worlds. The SAU defines memory regions as Secure or Non-Secure, while the IDAU provides additional implementation-specific memory attribution. When the Secure world attempts to access Non-Secure memory, the processor checks the SAU and IDAU configurations to determine if the access is permitted. If the access violates the security rules, the processor triggers a SecureFault exception, which can result in the system jumping to a fault handler or entering an undefined state, such as hanging or crashing. The address 0xEFFFFFFE is often associated with fault handling or exception vectors in ARM processors, further confirming that the issue is related to a security violation.
The problem described is not uncommon when working with ARMv8-M processors, especially when transitioning between Secure and Non-Secure worlds. The Cortex-M23’s security model is strict, and even minor misconfigurations can lead to access violations. The fact that the same code worked previously suggests that the system configuration or memory layout may have changed, or that the Secure world code is attempting to access a memory region that is no longer marked as Non-Secure. Additionally, the behavior of jumping to 0xEFFFFFFE indicates that the processor is encountering a fault condition, but the exact cause requires further investigation into the SAU, IDAU, and memory protection unit (MPU) configurations.
SAU Configuration Errors and Memory Attribution Mismatches
One of the primary causes of this issue is an incorrect or incomplete configuration of the Security Attribution Unit (SAU). The SAU is responsible for defining which memory regions are Secure and which are Non-Secure. If the SAU is not properly configured, the processor may misinterpret the security attributes of memory regions, leading to access violations. For example, if the SAU is disabled or misconfigured, the processor may treat all memory as Secure, preventing the Secure world from accessing Non-Secure memory regions. Conversely, if the SAU is configured incorrectly, it may mark certain memory regions as Non-Secure when they should be Secure, or vice versa.
Another potential cause is a mismatch between the SAU and the Implementation Defined Attribution Unit (IDAU). The IDAU provides additional memory attribution that is specific to the implementation of the processor. If the IDAU and SAU configurations are not aligned, the processor may enforce incorrect security attributes, leading to access violations. For instance, if the IDAU marks a memory region as Secure but the SAU marks it as Non-Secure, the processor may trigger a SecureFault when the Secure world attempts to access that region.
The ALLNS bit, which stands for "All Non-Secure," is another critical factor in this scenario. When the ALLNS bit is set, the processor treats all memory as Non-Secure, effectively bypassing the SAU and IDAU configurations. If the ALLNS bit is set incorrectly, it can lead to unexpected behavior, such as allowing the Secure world to access Non-Secure memory regions without proper permissions. However, if the ALLNS bit is reset, the processor enforces the SAU and IDAU configurations strictly, which can result in access violations if the configurations are incorrect.
Additionally, the memory protection unit (MPU) may play a role in this issue. The MPU is responsible for enforcing memory access permissions within the Secure and Non-Secure worlds. If the MPU is configured to restrict access to certain memory regions, it can prevent the Secure world from accessing Non-Secure memory, even if the SAU and IDAU configurations are correct. For example, if the MPU is configured to mark a Non-Secure memory region as read-only or inaccessible to the Secure world, the processor will trigger a fault when the Secure world attempts to access that region.
Finally, the issue may be related to the debugger configuration or the Keil MDK IDE. Debuggers can sometimes interfere with the normal operation of the processor, especially when single-stepping through code. If the debugger is not properly configured to handle Secure and Non-Secure world transitions, it may cause the processor to behave unexpectedly, such as jumping to address 0xEFFFFFFE or hanging. Additionally, the Keil MDK IDE may have specific settings or configurations that affect how the processor handles Secure and Non-Secure memory accesses, which could contribute to the issue.
Correcting SAU and IDAU Configurations and Debugging Secure World Access
To resolve this issue, the first step is to verify and correct the SAU and IDAU configurations. The SAU should be configured to accurately define the Secure and Non-Secure memory regions. This can be done by examining the SAU registers and ensuring that they match the intended memory layout. For example, if the Non-Secure memory region is located at 0x10040XXX, the SAU should be configured to mark this region as Non-Secure. The IDAU configuration should also be checked to ensure that it aligns with the SAU settings. If there are discrepancies between the SAU and IDAU configurations, they should be resolved to ensure consistent memory attribution.
Next, the ALLNS bit should be examined and set appropriately. If the Secure world needs to access Non-Secure memory, the ALLNS bit should be reset to enforce the SAU and IDAU configurations. However, if the ALLNS bit is set, it should be done with caution, as it can bypass the security mechanisms and potentially expose the system to vulnerabilities. The ALLNS bit should only be set if absolutely necessary and should be reset as soon as the access is complete.
The memory protection unit (MPU) should also be configured to allow the Secure world to access Non-Secure memory regions. This can be done by setting the appropriate MPU region attributes to permit read access from the Secure world. For example, if the Non-Secure memory region is located at 0x10040XXX, the MPU should be configured to mark this region as readable by the Secure world. The MPU configuration should be carefully reviewed to ensure that it does not inadvertently restrict access to the Non-Secure memory region.
If the issue persists after correcting the SAU, IDAU, and MPU configurations, the debugger and Keil MDK IDE settings should be examined. The debugger should be configured to handle Secure and Non-Secure world transitions properly. This may involve enabling specific debug features or adjusting the debugger settings to ensure that it does not interfere with the processor’s operation. The Keil MDK IDE may also have specific settings that affect how the processor handles Secure and Non-Secure memory accesses. These settings should be reviewed and adjusted as necessary to ensure that they align with the intended behavior.
Finally, if the issue is still unresolved, it may be necessary to examine the fault handling mechanisms of the Cortex-M23 processor. The address 0xEFFFFFFE is often associated with fault handling or exception vectors, so it is important to ensure that the fault handlers are properly configured and that they provide meaningful information about the cause of the fault. The SecureFault exception handler should be examined to determine why the processor is jumping to 0xEFFFFFFE and to identify any additional configuration or code issues that may be contributing to the problem.
In conclusion, the issue of the Secure world failing to access Non-Secure memory in the ARM Cortex-M23 processor is likely caused by incorrect SAU, IDAU, or MPU configurations, or by misconfigured debugger or IDE settings. By carefully reviewing and correcting these configurations, and by ensuring that the fault handling mechanisms are properly configured, the issue can be resolved, allowing the Secure world to access Non-Secure memory as intended.
