Cortex-A9 Boot Process and Secure World Initialization on NXP i.MX6
The Cortex-A9 processor, as part of the ARMv7-A architecture, supports TrustZone technology, which provides a secure environment for executing sensitive code. When the system boots, the processor starts in the secure state, specifically in the privileged Supervisor mode with the NS (Non-Secure) bit set to 0. This means that the initial boot code, typically the ROM code or a bootloader like U-Boot, runs in the secure world. The Monitor Vector Base Address Register (MVBAR) plays a crucial role in this process, as it holds the base address for exceptions taken to Monitor mode, which is the gateway between the secure and non-secure worlds.
The MVBAR is only accessible from Secure PL1 modes, meaning that it cannot be directly accessed from the non-secure world. This restriction is by design to ensure that only trusted code can modify the exception vectors for Monitor mode. However, this also means that initializing the MVBAR requires careful consideration of the boot process and the sequence of operations that transition the system from the secure to the non-secure world.
On platforms like the NXP i.MX6, the ROM code typically boots the system in the secure world. The next stage, often U-Boot, may then decide whether to remain in the secure world or switch to the non-secure world before booting the Linux kernel. The decision to switch to the non-secure world is critical because once the system is in the non-secure world, the only way to return to the secure world is through a Secure Monitor Call (SMC) exception, which relies on the MVBAR being correctly initialized.
Secure Monitor Call (SMC) and MVBAR Initialization Challenges
The SMC instruction is used to generate a synchronous exception that transitions the processor from the non-secure world to the secure world. This exception is handled by the Monitor mode, which uses the exception vectors defined by the MVBAR. Therefore, the MVBAR must be correctly initialized before any SMC calls can be made. However, initializing the MVBAR is not straightforward because it requires access to the secure world, and the system must be in a state where it can safely modify the MVBAR without compromising security.
One of the challenges in initializing the MVBAR is determining the appropriate point in the boot process to do so. If the MVBAR is initialized too early, it may not be possible to ensure that the secure world is fully set up and ready to handle exceptions. If it is initialized too late, the system may already be in the non-secure world, making it impossible to access the MVBAR directly. This timing issue is further complicated by the fact that different platforms may handle the transition from the secure to the non-secure world differently.
For example, on some platforms, the ROM code may switch to the non-secure world before executing the next stage of the boot process, while on others, it may remain in the secure world. This variability means that the approach to initializing the MVBAR must be tailored to the specific platform and boot sequence. Additionally, the use of bootloaders like U-Boot adds another layer of complexity, as U-Boot may need to be modified to support the secure world and the initialization of the MVBAR.
Implementing Secure Extensions and MVBAR Access in U-Boot
Given that the Cortex-A9 processor boots in the secure world, the initial stages of the boot process, including the execution of the ROM code and U-Boot, occur in the secure world. This provides an opportunity to initialize the MVBAR before transitioning to the non-secure world. However, this requires careful modification of U-Boot to ensure that it can handle the secure world and properly initialize the MVBAR.
One approach is to modify U-Boot to include a secure monitor that can handle SMC exceptions and manage the transition between the secure and non-secure worlds. This secure monitor would be responsible for initializing the MVBAR and setting up the exception vectors for Monitor mode. Once the MVBAR is initialized, U-Boot can then switch to the non-secure world and continue the boot process, knowing that the secure world is properly set up to handle SMC exceptions.
Another consideration is the use of ARM Trusted Firmware (ATF) or other trusted execution environments (TEEs) that provide a standardized way to manage the secure world and handle transitions between the secure and non-secure worlds. These frameworks often include support for initializing the MVBAR and handling SMC exceptions, which can simplify the process of implementing secure extensions in U-Boot.
In the case of the NXP i.MX6 platform, it is important to determine whether the ROM code or U-Boot is responsible for switching to the non-secure world. If U-Boot is responsible for this transition, it must be modified to initialize the MVBAR and set up the secure monitor before switching to the non-secure world. This ensures that the secure world is ready to handle SMC exceptions and that the MVBAR is correctly initialized before any SMC calls are made.
In summary, accessing and initializing the MVBAR in the Cortex-A9 processor with TrustZone requires a deep understanding of the boot process, the role of the secure monitor, and the specific behavior of the platform being used. By carefully modifying U-Boot or using a trusted execution environment like ATF, it is possible to ensure that the MVBAR is correctly initialized and that the secure world is ready to handle SMC exceptions, enabling a smooth transition between the secure and non-secure worlds.
