Understanding the EL3 Execution Requirement for Custom Applications on Cortex-A53
The requirement to run custom applications at Exception Level 3 (EL3) on a Cortex-A53 core, particularly on an i.MX8-based platform, presents a unique challenge. EL3 is traditionally reserved for firmware and security-critical code, such as the ARM Trusted Firmware (ATF) or BL31, which handles secure monitor calls and transitions between the Secure and Non-secure states. The Cortex-A53 processor, part of the ARMv8-A architecture, implements four exception levels (EL0 to EL3), with EL3 being the most privileged level. This level is typically used for secure monitor code, which manages the switching between the Secure and Non-secure worlds.
The boot flow on the i.MX8 platform involves a hand-off from the ARM Trusted Firmware (BL31) to U-Boot (BL33), where the transition from EL3 to EL2 occurs. U-Boot then operates at EL2, which is the Hypervisor level, and this is the standard behavior for most ARM-based systems. However, the requirement to keep U-Boot and custom applications running at EL3 is atypical and requires a deep understanding of the ARMv8-A architecture, the boot process, and the modifications needed to the ARM Trusted Firmware (ATF) to support this use case.
The primary challenge lies in the fact that EL3 is not designed to run large applications or bootloaders like U-Boot. EL3 is intended for small, tightly focused firmware that handles secure state switching and other security-critical tasks. Running U-Boot or custom applications at EL3 could lead to instability, security vulnerabilities, and potential conflicts with the secure monitor code. Therefore, the first step in addressing this requirement is to understand why the BSP vendor has imposed this requirement and whether it is truly necessary to run the application at EL3. If the goal is to access secure state or Physical Address (PA) space, it might be more appropriate to target S_EL0 or S_EL1, which are the secure exception levels for user and kernel modes, respectively.
Customizing ARM Trusted Firmware (BL31) for EL3 Execution
To achieve EL3 execution for custom applications, modifications to the ARM Trusted Firmware (BL31) are necessary. BL31 is responsible for handling the transition from the secure world (EL3) to the non-secure world (EL2/EL1) and vice versa. By default, BL31 sets up the system to transition to EL2 before handing control to U-Boot (BL33). To keep U-Boot and custom applications running at EL3, the BL31 code must be modified to avoid this transition.
One approach is to modify the bl31_main function in BL31, which is responsible for initializing the secure monitor and setting up the exception levels. The bl31_main function typically calls runtime_exceptions_init to set up the exception vectors and bl31_plat_runtime_setup to configure the platform-specific runtime services. To prevent the transition to EL2, the code that sets the SCR_EL3 register (Secure Configuration Register) to configure the next exception level must be modified. Specifically, the SCR_EL3.RW bit, which determines whether the next lower level is AArch64 or AArch32, and the SCR_EL3.HCE bit, which enables Hypervisor Call (HVC) instructions at EL2, need to be carefully configured.
Another approach is to use the alternative boot flow provided by the ARM Trusted Firmware, which allows booting an EL3 payload instead of BL31. This approach involves replacing BL31 with a custom EL3 payload that can handle the secure monitor functionality while also running the custom application at EL3. The EL3 payload would need to implement the necessary secure monitor calls and manage the transition between secure and non-secure states, if required. This approach provides more flexibility but also requires a deeper understanding of the ARMv8-A architecture and the secure monitor code.
Implementing and Debugging EL3 Execution for Custom Applications
Once the necessary modifications to BL31 or the EL3 payload have been made, the next step is to implement and debug the custom application running at EL3. This involves ensuring that the application can coexist with the secure monitor code and that it does not interfere with the secure state switching or other security-critical tasks. One of the key challenges is managing the memory layout and ensuring that the application does not overwrite critical secure monitor data or code.
The ARMv8-A architecture provides several mechanisms for managing memory at different exception levels, including the Memory Management Unit (MMU) and the Translation Table Base Registers (TTBRs). At EL3, the MMU is typically configured to use a flat memory map, where all memory is treated as secure. However, if the custom application needs to access non-secure memory, the MMU configuration must be carefully managed to avoid security vulnerabilities. The MAIR_EL3 (Memory Attribute Indirection Register) and TCR_EL3 (Translation Control Register) must be configured to define the memory attributes and translation table walk behavior, respectively.
Debugging EL3 execution can be challenging due to the limited debugging tools available at this privilege level. The ARM CoreSight architecture provides some debugging capabilities, but these are typically restricted to lower exception levels. To debug EL3 code, it may be necessary to use a combination of hardware breakpoints, software breakpoints, and logging. The ESR_EL3 (Exception Syndrome Register) can be used to diagnose exceptions and interrupts that occur at EL3, while the FAR_EL3 (Fault Address Register) can provide the address of the faulting instruction or data access.
In addition to debugging, it is important to thoroughly test the custom application running at EL3 to ensure that it does not introduce security vulnerabilities or instability. This includes testing the application under various conditions, such as different memory configurations, interrupt scenarios, and secure state transitions. The ARMv8-A architecture provides several features for testing and validating secure code, including the SP_EL3 (Stack Pointer) and SPSR_EL3 (Saved Program Status Register), which can be used to save and restore the processor state during secure monitor calls.
In conclusion, running custom applications at EL3 on a Cortex-A53 core is a complex task that requires a deep understanding of the ARMv8-A architecture, the ARM Trusted Firmware, and the secure monitor code. By carefully modifying BL31 or using an EL3 payload, it is possible to achieve EL3 execution for custom applications. However, this approach requires careful management of memory, debugging, and testing to ensure that the application does not compromise the security or stability of the system.
