ARM Cortex-A TZASC Configuration Issues in Secure Mode

TZASC Region Configuration and Secure State Access Problems

The TrustZone Address Space Controller (TZASC) is a critical component in ARM Cortex-A processors for managing memory access permissions between secure and non-secure worlds. When configuring the TZASC, one common issue arises when the system fails to enforce secure memory access restrictions, particularly when the processor remains in secure mode. This issue is often observed during bootloader execution, where the system inadvertently allows access to memory regions that should be restricted to non-secure world applications.

In the described scenario, the TZASC is configured with two regions: Region 0 with a base address of 0x1 and a size of 2GB, and Region 1 with a base address of 0x80800000 and a size of 8MB. Both regions are assigned secure read/write permissions. Despite this configuration, the system successfully loads the kernel OS image into Region 1 without generating any access violation errors. This behavior suggests that the TZASC configuration is not being enforced as expected.

The root cause of this issue lies in the processor’s operational state. By default, ARM Cortex-A processors boot in secure mode, granting unrestricted access to all memory regions, including those configured as secure in the TZASC. The TZASC registers themselves can only be programmed in secure mode, but their enforcement of access restrictions only becomes effective when the processor transitions to non-secure mode. This dual-state requirement is often overlooked during system initialization, leading to unexpected memory access behavior.

To confirm whether the bootloader is running in secure mode, one can inspect the NS bit in the Secure Configuration Register (SCR). If the NS bit is cleared, the processor is in secure mode. Additionally, the Monitor mode, which facilitates transitions between secure and non-secure states, must be properly configured to ensure that the TZASC settings are enforced correctly.

Secure Mode Retention and TZASC Register Accessibility

The primary cause of the TZASC configuration not being enforced is the processor’s retention in secure mode. When the processor remains in secure mode, it bypasses the TZASC access restrictions, as secure mode inherently grants full access to all memory regions. This behavior is by design, allowing secure world software to configure the TZASC and other security features without being hindered by access restrictions.

Another contributing factor is the improper transition from secure to non-secure mode. The ARM architecture requires a specific sequence of operations to switch from secure to non-secure mode, involving the use of Monitor mode. If this transition is not executed correctly, the processor remains in secure mode, and the TZASC access restrictions are not applied.

The TZASC registers themselves are only accessible in secure mode, which means that any configuration changes must be made before transitioning to non-secure mode. However, the enforcement of these configurations only takes effect once the processor is in non-secure mode. This dichotomy between configuration and enforcement is a common source of confusion and can lead to situations where the TZASC settings appear to be ignored.

To further complicate matters, the TZASC configuration must be consistent with the memory map of the system. If the memory regions defined in the TZASC do not align with the actual memory layout, the access restrictions may not be applied as intended. This misalignment can occur due to incorrect base address or size specifications, or due to overlapping regions that create ambiguous access permissions.

Implementing Secure State Transition and TZASC Enforcement

To resolve the TZASC configuration issues, a systematic approach is required to ensure that the processor transitions from secure to non-secure mode correctly and that the TZASC settings are enforced as intended. The following steps outline the necessary actions to achieve this:

1. Verify Secure Mode State: Before making any TZASC configuration changes, confirm that the processor is in secure mode by checking the NS bit in the Secure Configuration Register (SCR). If the NS bit is set, the processor is in non-secure mode, and any TZASC register accesses will result in an undefined instruction exception.

2. Configure TZASC Regions: Define the memory regions in the TZASC with the appropriate base addresses, sizes, and access permissions. Ensure that the regions do not overlap and that they align with the system’s memory map. For example, Region 0 can be configured as a secure region covering the entire address space, while Region 1 can be defined as a non-secure region for the kernel OS image.

3. Enable TZASC: After configuring the TZASC regions, enable the TZASC by setting the appropriate control bits in the TZASC control register. This step ensures that the TZASC is active and ready to enforce the configured access restrictions.

4. Prepare for Secure to Non-Secure Transition: Before transitioning to non-secure mode, ensure that all necessary secure world tasks are completed, and that the non-secure world software is ready to take over. This includes setting up the non-secure vector table and initializing any non-secure peripherals.

5. Execute Secure to Non-Secure Transition: Use the ARMv7-A SMC (Secure Monitor Call) instruction to enter Monitor mode and perform the transition from secure to non-secure mode. This involves setting the NS bit in the SCR and configuring the Non-Secure Vector Table Address Register (VBAR) to point to the non-secure vector table.

6. Verify TZASC Enforcement: After transitioning to non-secure mode, verify that the TZASC access restrictions are being enforced by attempting to access the secure memory regions. Any unauthorized access attempts should result in a memory abort exception, confirming that the TZASC is functioning correctly.

7. Debugging and Troubleshooting: If the TZASC access restrictions are not being enforced, use a debugger to inspect the TZASC registers and confirm that they are configured as intended. Additionally, check the processor’s mode and state to ensure that the transition to non-secure mode was successful.

By following these steps, the TZASC configuration issues can be resolved, ensuring that the memory access restrictions are enforced correctly and that the system operates securely. This approach not only addresses the immediate problem but also provides a framework for future TZASC configurations and secure state transitions.

In conclusion, the TZASC is a powerful tool for managing memory access permissions in ARM Cortex-A processors, but its effective use requires a thorough understanding of the processor’s secure and non-secure states. By carefully configuring the TZASC and ensuring a proper transition from secure to non-secure mode, system designers can achieve the desired level of security and reliability in their embedded systems.