• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 349 subscribers
  • Views 5380 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Does CCI-400 guarantees cache coherency between secure and non-secure worlds?

Kay

Hi Experts,

I'm developing some kind of Secure OS on A57/53 big.LITTLE SoC.

While multi-core testing, I'm facing some wired problem on my world shared memory mechanism.

When I run world shared memory test on a single core (using affinity), it works well for a hundred of thousand times.

But once multi-core enabled, it sometimes fails.

Meaning to say, in the secure there is no content on the memory which is shared by non-secure.

I'm now doubting everything.

I believe that the CCI-400 works well between the big and LITTLE cluster's for cache coherency in the non-secure world.

But when world change occurs from non-secure to secure, does CCI-400 still guarantee cache coherency between two worlds?

Or Should I use any cache maintenance instruction?


My world shared memory mechanism is like this;

  1. Allocate some amount of memory from the non-secure user space.
  2. Ask linux kernel driver passing these virtual address and size to share memory with the secure world.
  3. Kernel driver queries current TTBA, and issues smc call with these three parameters.
  4. Secure OS gets the TTBA, VA and size,
  5. and maps the TTBA into secure os' process, gets pagetable entries of the shared memory, and finally maps the shared memory

It might be a silly question, please advice me.

Parents
  • 0 Arm Employee Badge in reply to Matt Sealey

    I should have answered the title question clearly too - the CCI-400, and all cache-coherent interconnects by ARM, do not assure coherency between the Secure and Non-Secure worlds because they are two separate physical address spaces.

    You can think of the NS bit (which is a conjunction of SCR.NS, translation table entry NS, and whether you're not in Monitor mode) as a 33rd/41st/49th address bit (Short, LPAE, AArch64 physical addressing). In this sense, the NS+32-bit address 0x1_0000_8000 (NS) is not the same as NS+32-bit address 0x0_0000_8000 (S) and, obviously, two 'different' addresses need not be coherent.

    The CCI-400 will, however, assure that all NS transactions are coherent in and of themselves, and all Secure transactions are coherent in and of themselves - so if you stay mapped as Non-Secure from Linux to your Secure OS, then the coherency is well-managed. Having the interconnect assume that the Secure and Non-Secure worlds have the same underlying memory map would be a violation of the Security Extensions.

    Ta,

    Matt

Reply
  • 0 Arm Employee Badge in reply to Matt Sealey

    I should have answered the title question clearly too - the CCI-400, and all cache-coherent interconnects by ARM, do not assure coherency between the Secure and Non-Secure worlds because they are two separate physical address spaces.

    You can think of the NS bit (which is a conjunction of SCR.NS, translation table entry NS, and whether you're not in Monitor mode) as a 33rd/41st/49th address bit (Short, LPAE, AArch64 physical addressing). In this sense, the NS+32-bit address 0x1_0000_8000 (NS) is not the same as NS+32-bit address 0x0_0000_8000 (S) and, obviously, two 'different' addresses need not be coherent.

    The CCI-400 will, however, assure that all NS transactions are coherent in and of themselves, and all Secure transactions are coherent in and of themselves - so if you stay mapped as Non-Secure from Linux to your Secure OS, then the coherency is well-managed. Having the interconnect assume that the Secure and Non-Secure worlds have the same underlying memory map would be a violation of the Security Extensions.

    Ta,

    Matt

Children
No data