Secure State Verification in ARMv8 AArch64: The Challenge of Proving Secure EL1 Execution
In ARMv8 AArch64 architectures, the distinction between secure and non-secure states is fundamental to the TrustZone security model. The secure state is designed to provide a trusted execution environment (TEE) for sensitive operations, while the non-secure state handles general-purpose tasks. However, verifying that code is indeed executing in the secure state, specifically at Exception Level 1 (EL1), presents a unique challenge. This is particularly relevant when developing secure software such as OP-TEE (Open Portable Trusted Execution Environment), where proving the execution environment’s security is critical for compliance and trustworthiness.
The core issue revolves around the inability of secure EL1 to directly access the Secure Configuration Register (SCR_EL3), which contains the Non-Secure (NS) bit. This bit is pivotal in determining whether the current execution state is secure or non-secure. Since SCR_EL3 is only accessible at EL3, secure EL1 cannot directly read this register to confirm its execution state. This limitation necessitates alternative methods to ascertain the secure state, which must be both reliable and compliant with ARM’s architectural specifications.
SCR_EL3 Access Restrictions and Indirect State Determination
The primary obstacle in verifying secure state execution at EL1 stems from the hierarchical access controls inherent in the ARMv8 architecture. SCR_EL3, which governs the configuration of the secure state, is only accessible at EL3. This design ensures that lower exception levels, including secure EL1, cannot directly manipulate or read the secure state configuration, thereby maintaining the integrity of the TrustZone security model.
The NS bit within SCR_EL3 is the definitive indicator of whether the current execution state is secure or non-secure. When the NS bit is set to 0, the system is in the secure state, and when it is set to 1, the system is in the non-secure state. However, since secure EL1 cannot access SCR_EL3, it cannot directly read the NS bit to determine its execution state. This restriction necessitates the use of indirect methods to infer the secure state.
One potential approach involves leveraging the fact that certain registers and system behaviors are influenced by the secure state. For instance, the Secure Physical Timer (SPT) and Non-Secure Physical Timer (NSPT) are distinct and can be used to infer the execution state. Additionally, the behavior of memory accesses to secure and non-secure memory regions can provide clues about the current state. However, these methods are indirect and may not provide the definitive proof required in certain scenarios.
Implementing Secure State Verification Through System Register Analysis and Memory Access Patterns
To address the challenge of verifying secure state execution at EL1, a combination of system register analysis and memory access pattern examination can be employed. These methods provide a robust framework for inferring the secure state without directly accessing SCR_EL3.
System Register Analysis:
Certain system registers in the ARMv8 architecture are influenced by the secure state and can be accessed at EL1. For example, the CurrentEL register indicates the current exception level, and the SPSR_EL1 register contains the saved processor state, including the security state of the previously executed exception level. By examining these registers, it is possible to infer the secure state indirectly.
The CurrentEL register can be read to confirm that the code is executing at EL1. While this does not directly indicate the secure state, it is a necessary precondition for secure EL1 execution. The SPSR_EL1 register, which holds the state of the processor before entering EL1, can provide additional clues. If the previous state was EL3, and the NS bit was cleared, it can be inferred that the current execution is in the secure state.
Memory Access Patterns:
Another method involves examining the behavior of memory accesses to secure and non-secure memory regions. The ARMv8 architecture partitions memory into secure and non-secure regions, and the behavior of memory accesses can vary depending on the current execution state. By attempting to access a secure memory region and observing the result, it is possible to infer the secure state.
For instance, if a memory access to a secure region succeeds, it suggests that the current execution state is secure. Conversely, if the access fails or results in a fault, it may indicate that the execution state is non-secure. This method, while indirect, can provide additional evidence to support the secure state verification.
Combining Methods for Robust Verification:
To achieve a more robust verification, the above methods can be combined. By cross-referencing the results of system register analysis with memory access patterns, a more definitive conclusion about the secure state can be reached. For example, if the CurrentEL register confirms execution at EL1, and memory accesses to secure regions succeed, it provides strong evidence that the code is executing in the secure state.
Additionally, the use of secure world-specific features, such as the Secure Physical Timer, can further corroborate the secure state. The Secure Physical Timer is only accessible in the secure state, and its successful use can serve as an additional indicator of secure execution.
Implementation Considerations:
When implementing these verification methods, it is crucial to consider the potential for false positives and false negatives. For instance, certain configurations or system states may result in ambiguous outcomes. Therefore, it is advisable to use multiple independent methods to cross-verify the secure state.
Furthermore, the verification process should be designed to minimize its impact on system performance and security. Excessive use of memory accesses or system register reads can introduce latency and potential vulnerabilities. Therefore, the verification should be performed judiciously, ideally during initialization or at specific checkpoints, rather than continuously.
Conclusion:
Verifying secure state execution at EL1 in ARMv8 AArch64 architectures is a complex but essential task, particularly for secure software development such as OP-TEE. While direct access to SCR_EL3 is restricted at EL1, a combination of system register analysis and memory access pattern examination can provide reliable indirect methods for secure state verification. By carefully implementing and cross-referencing these methods, it is possible to achieve a robust and compliant verification of secure execution, thereby ensuring the integrity and trustworthiness of the secure software environment.
