Suppose code running in the non-secure state wants to invalidate secure address 0x8000. Does the AArch64 instruction set support this?
Assume a system where secure and non-secure memory are in the same location. In other words, secure address 0x8000 and non-secure address 0x8000 are backed by the same physical memory. Furthermore, assume the translation tables are set so that virtual address 0x8000 maps to physical address 0x8000.
The code running in the non-secure state can execute "DC IVAC, x0" with x0 = 0x8000 to invalidate the cache line corresponding to virtual address 0x8000, but in the non-secure state the NS bits in the translation tables are ignored so this would only invalidate non-secure address 0x8000, which is not what we want (we wanted to invalidate secure address 0x8000). Is there a different way to invalidate secure address 0x8000 from code running in the non-secure state?
----
Why would we want to do this?
I am building a system where 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 invalidates the code segment of software B so that future instruction fetches go to memory.
jatron said:Suppose code running in the non-secure state wants to invalidate secure address 0x8000. Does the AArch64 instruction set support this?
No.
jatron said:I am building a system where 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 invalidates the code segment of software B so that future instruction fetches go to memory.
In your flow, is the association of the backing memory changing from the NS PA space to the S PA space? (Via something like a GPT or a TZASC)
I wouldn't expect you to ever execute from NS PAs while in Secure state, and there's a SCR_EL3 control to prevent it. So assuming you're moving the memory between PA spaces as part of the sequence, then that software flow would need to include the appropriate cleans and invalidates in both PA spaces.
The process of changing the memory's association would have to be in Secure (or Root) state, as you'd not trust Non-secure state to control which memories where Secure or not. From Secure (or Root) state, you can operate on both NS and S addresses.
Martin Weidmann said:No.
Thanks Martin. This answered my question
Martin Weidmann said:In your flow, is the association of the backing memory changing from the NS PA space to the S PA space? (Via something like a GPT or a TZASC)
Yes, initially software A (running in the non-secure state) can write to the backing memory where software B is loaded. Sometime later we lock down the memory where software B is loaded so that non-secure state cannot access it.