Secure and Non-Secure Memory Overlap in ARM A-Profile Systems
In ARM A-Profile architectures, particularly those implementing the ARMv8-A and ARMv9-A instruction sets, the concept of secure and non-secure memory spaces is fundamental to the TrustZone security model. TrustZone partitions the system into two worlds: the Secure world and the Non-Secure world. Each world has its own memory address space, and these spaces can overlap in physical memory. This overlap is managed through the use of the Non-Secure (NS) bit in the translation tables, which determines whether a given memory access is treated as secure or non-secure.
In the scenario described, the physical memory at address 0x8000 is shared between the secure and non-secure worlds. This means that both secure and non-secure virtual addresses can map to the same physical memory location. However, the NS bit in the translation tables ensures that accesses from the non-secure world are treated as non-secure, while accesses from the secure world are treated as secure. This separation is crucial for maintaining the integrity and confidentiality of secure data.
When software running in the non-secure state attempts to invalidate a cache line corresponding to a secure address, it encounters a fundamental limitation. The ARM architecture does not allow non-secure software to directly manipulate secure cache lines. This is by design, as allowing non-secure software to invalidate secure cache lines would undermine the security model. The non-secure software can only invalidate cache lines that are marked as non-secure in the translation tables. This means that even if the physical memory is shared, the non-secure software cannot invalidate the secure cache line at address 0x8000.
Limitations of Non-Secure Cache Operations on Secure Memory
The inability of non-secure software to invalidate secure cache lines is rooted in the ARM architecture’s security model. The ARMv8-A and ARMv9-A architectures provide a set of cache maintenance instructions, such as DC IVAC, which are used to invalidate cache lines. However, these instructions operate within the context of the current security state. When executed in the non-secure state, these instructions only affect cache lines that are marked as non-secure in the translation tables.
The NS bit in the translation tables plays a critical role in this process. When a memory access is performed, the NS bit determines whether the access is treated as secure or non-secure. This bit is used by the Memory Management Unit (MMU) to enforce the security model. When non-secure software executes a cache maintenance instruction, the MMU uses the NS bit to ensure that only non-secure cache lines are affected. This means that even if the physical memory is shared, the non-secure software cannot invalidate the secure cache line.
This limitation is particularly relevant in systems where secure and non-secure software need to share memory. For example, in the scenario described, software A (running in the non-secure state) loads software B (running in the secure state) into memory. Before passing control to software B, software A needs to invalidate the cache lines corresponding to the code segment of software B to ensure that future instruction fetches go to memory rather than the cache. However, because software A is running in the non-secure state, it cannot directly invalidate the secure cache lines.
Secure State Cache Management and Transition Protocols
To address the limitation of non-secure cache operations on secure memory, the ARM architecture provides mechanisms for managing cache lines in the secure state. These mechanisms are accessible only to software running in the secure state, ensuring that secure cache lines cannot be manipulated by non-secure software.
One approach to managing secure cache lines is to transition the memory from the non-secure physical address (PA) space to the secure PA space. This transition can be achieved using mechanisms such as the Granule Protection Table (GPT) or the TrustZone Address Space Controller (TZASC). These mechanisms allow the secure software to control which memory regions are accessible to the non-secure world and which are reserved for the secure world.
When the memory is transitioned from the non-secure PA space to the secure PA space, the secure software must perform the necessary cache maintenance operations. This includes cleaning and invalidating the cache lines in both the non-secure and secure PA spaces. The cleaning operation ensures that any dirty data in the cache is written back to memory, while the invalidation operation ensures that the cache lines are marked as invalid, forcing future accesses to fetch data from memory.
The process of transitioning memory between the non-secure and secure PA spaces must be performed by software running in the secure state. This is because the secure state has access to both the non-secure and secure PA spaces, while the non-secure state only has access to the non-secure PA space. The secure software can use the DC CIVAC instruction to clean and invalidate cache lines in both PA spaces, ensuring that the cache is properly maintained during the transition.
In addition to cache maintenance, the secure software must also ensure that the memory is properly locked down to prevent non-secure access. This can be achieved using the TZASC or similar mechanisms to configure the memory regions as secure-only. Once the memory is locked down, non-secure software will no longer be able to access the memory, ensuring that the secure data remains protected.
The secure software must also ensure that the cache maintenance operations are performed in the correct order. For example, if the memory is being transitioned from the non-secure PA space to the secure PA space, the secure software must first clean the cache lines in the non-secure PA space to ensure that any dirty data is written back to memory. The secure software can then invalidate the cache lines in the non-secure PA space to ensure that future accesses fetch data from memory. Finally, the secure software can invalidate the cache lines in the secure PA space to ensure that the secure data is fetched from memory rather than the cache.
In summary, the ARM architecture provides mechanisms for managing secure cache lines, but these mechanisms are only accessible to software running in the secure state. Non-secure software cannot directly manipulate secure cache lines, and any cache maintenance operations must be performed by secure software. This ensures that the security model is maintained and that secure data remains protected from non-secure access.
