ARM Cortex-M33 TrustZone Partitioning and Non-Secure Peripheral Initialization
The ARM Cortex-M33 processor, with its TrustZone security extension, provides a robust mechanism for partitioning code and resources into secure and non-secure worlds. This partitioning is essential for applications requiring high security, such as IoT devices handling sensitive data. However, the separation of secure and non-secure worlds introduces complexities, particularly when peripherals need to be accessed from the non-secure world. In this scenario, the NXP LPC55S69 microcontroller, which features a Cortex-M33 core, is being used to perform secure calculations and then transmit the results via WiFi from the non-secure world. The WiFi module, a Mikroe WiFi 10 click board, is connected via the Mikro bus. While initializing the WiFi module in the secure world works without issues, attempts to initialize it in the non-secure world result in hardfaults.
Hardfaults in ARM Cortex-M processors are typically caused by illegal memory accesses, invalid instruction execution, or improper configuration of the processor or peripherals. In the context of TrustZone, hardfaults can also arise from violations of the security partitioning rules. For instance, a non-secure world attempting to access a secure-only peripheral or memory region will trigger a hardfault. Additionally, improper configuration of the Security Attribution Unit (SAU) or the Implementation Defined Attribution Unit (IDAU) can lead to unexpected behavior.
The SAU and IDAU are critical components in the TrustZone architecture, as they define the security attributes of memory regions and peripherals. The SAU allows the software to configure up to eight memory regions as secure or non-secure, while the IDAU provides a hardware-defined security attribution that cannot be altered by software. When a peripheral, such as the WiFi module, is intended to be used in the non-secure world, it is essential to ensure that its memory-mapped registers and any associated DMA buffers are configured as non-secure. Failure to do so will result in a hardfault when the non-secure world attempts to access these resources.
Memory Attribution Misconfiguration and Peripheral Access Violations
One of the primary causes of hardfaults during non-secure world WiFi initialization is the misconfiguration of memory and peripheral security attributes. The Cortex-M33 TrustZone architecture requires that all memory regions and peripherals be explicitly assigned to either the secure or non-secure world. If the WiFi module’s registers or associated memory regions are incorrectly marked as secure, any attempt by the non-secure world to access these resources will result in a hardfault.
The SAU configuration is particularly important in this context. The SAU allows the software to define up to eight memory regions, each with a specific security attribute. These regions can be configured as secure, non-secure, or non-secure callable. The non-secure callable regions are used to store secure entry points that can be called from the non-secure world. If the SAU is not properly configured to mark the WiFi module’s memory regions as non-secure, the non-secure world will be unable to access these regions, leading to a hardfault.
Another potential cause of hardfaults is the improper configuration of the IDAU. The IDAU provides a hardware-defined security attribution that cannot be changed by software. This means that certain memory regions and peripherals may be inherently secure, and any attempt to access them from the non-secure world will result in a hardfault. In the case of the NXP LPC55S69, the IDAU configuration must be carefully reviewed to ensure that the WiFi module’s memory regions are not marked as secure by default.
Additionally, the initialization sequence of the WiFi module in the non-secure world must be carefully managed. The non-secure world may not have the necessary privileges to configure certain aspects of the WiFi module, such as its clock or power management settings. If these settings are not properly configured before attempting to initialize the WiFi module, the initialization process may fail, resulting in a hardfault.
Configuring SAU and IDAU for Non-Secure WiFi Initialization
To resolve the hardfaults during non-secure world WiFi initialization, it is essential to carefully configure the SAU and IDAU to ensure that the WiFi module’s memory regions and peripherals are accessible from the non-secure world. The following steps outline the process for configuring the SAU and IDAU, as well as other necessary settings, to enable successful WiFi initialization in the non-secure world.
First, the SAU must be configured to mark the WiFi module’s memory regions as non-secure. This involves defining the memory regions associated with the WiFi module in the SAU configuration registers. The SAU configuration registers allow the software to specify the base address, size, and security attribute of each memory region. For the WiFi module, the memory regions containing its registers and any associated DMA buffers must be marked as non-secure. This ensures that the non-secure world can access these regions without triggering a hardfault.
Next, the IDAU configuration must be reviewed to ensure that the WiFi module’s memory regions are not marked as secure by default. The IDAU provides a hardware-defined security attribution that cannot be changed by software, so it is important to verify that the WiFi module’s memory regions are not inherently secure. If the IDAU configuration marks these regions as secure, it may be necessary to modify the hardware design or use a different WiFi module that is compatible with the non-secure world.
Once the SAU and IDAU configurations are properly set, the initialization sequence of the WiFi module in the non-secure world must be carefully managed. This includes configuring the WiFi module’s clock and power management settings before attempting to initialize the module. The non-secure world may not have the necessary privileges to configure these settings, so it may be necessary to perform these configurations in the secure world before transitioning to the non-secure world. This can be achieved by using a secure service that configures the WiFi module’s clock and power management settings and then transitions to the non-secure world for the remainder of the initialization process.
In addition to configuring the SAU and IDAU, it is also important to ensure that the WiFi module’s interrupt handlers are properly configured for the non-secure world. The Cortex-M33 TrustZone architecture allows interrupts to be assigned to either the secure or non-secure world. If the WiFi module’s interrupts are assigned to the secure world, the non-secure world will be unable to handle these interrupts, leading to a hardfault. To avoid this, the WiFi module’s interrupts must be assigned to the non-secure world in the Nested Vectored Interrupt Controller (NVIC).
Finally, it is important to verify that the WiFi module’s firmware is compatible with the non-secure world. Some WiFi modules may have firmware that assumes it is running in the secure world, and attempting to run this firmware in the non-secure world may result in a hardfault. If the WiFi module’s firmware is not compatible with the non-secure world, it may be necessary to update the firmware or use a different WiFi module that is compatible with the non-secure world.
By carefully configuring the SAU and IDAU, managing the initialization sequence, and ensuring that the WiFi module’s interrupts and firmware are compatible with the non-secure world, it is possible to resolve the hardfaults and successfully initialize the WiFi module in the non-secure world. This allows the secure world to perform its calculations and pass the results to the non-secure world for transmission via WiFi, providing a secure and efficient solution for IoT applications.
