This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[A-profile] Is it possible to invalidate secure physical addresses from the normal world?

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.

Parents
  • No.

    Thanks Martin. This answered my question

    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.

Reply
  • No.

    Thanks Martin. This answered my question

    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.

Children
No data