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

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
  • Hi kaylee,

    The first and easiest question to ask is how you're mapping the target address in the secure world. A cache line fetched while executing in the Non-Secure world will be tagged as Non-Secure. A Secure OS mapping the same physical address to virtual address with the NS bit not set (therefore it's "secure memory") in the translation table entry will be tagged as Secure. In this way the same numerical physical address can be in the cache twice - a secure copy and a non-secure copy. Consider that the Security extensions define the S and NS physical address spaces as entirely separate (even if the system is designed such that they are the same view of the memory map).

    If your secure OS is mapping memory from the non-secure world then it needs to map it with the NS bit set in the appropriate translation table entries. Here's the trick - it seems you're implying that you're directly re-using the mappings passed by the Non-Secure OS by referencing that NS OS's tables. In this case Linux makes no assumptions about whether memory is secure or non-secure - if secure, it wants the NS bit to be unset, if non-secure then the NS bit is ignored anyway, so it just doesn't use the bit. If you're just copying non-secure descriptors and modifying the address, and the NS bit is 0, then it's explicitly secure memory while you're in the secure world. Note that you also need to be careful accessing the table entries from the secure world!

    If it's not as simple as that, then I am sure we can dive into it a little more.

    It is usually best to assume all addresses passed from the Non-Secure world are to be set NS (specifically), and pass physical (not virtual) addresses, and this is how most reliable SMC APIs are designed.

    Ta,

    Matt

Reply
  • Hi kaylee,

    The first and easiest question to ask is how you're mapping the target address in the secure world. A cache line fetched while executing in the Non-Secure world will be tagged as Non-Secure. A Secure OS mapping the same physical address to virtual address with the NS bit not set (therefore it's "secure memory") in the translation table entry will be tagged as Secure. In this way the same numerical physical address can be in the cache twice - a secure copy and a non-secure copy. Consider that the Security extensions define the S and NS physical address spaces as entirely separate (even if the system is designed such that they are the same view of the memory map).

    If your secure OS is mapping memory from the non-secure world then it needs to map it with the NS bit set in the appropriate translation table entries. Here's the trick - it seems you're implying that you're directly re-using the mappings passed by the Non-Secure OS by referencing that NS OS's tables. In this case Linux makes no assumptions about whether memory is secure or non-secure - if secure, it wants the NS bit to be unset, if non-secure then the NS bit is ignored anyway, so it just doesn't use the bit. If you're just copying non-secure descriptors and modifying the address, and the NS bit is 0, then it's explicitly secure memory while you're in the secure world. Note that you also need to be careful accessing the table entries from the secure world!

    If it's not as simple as that, then I am sure we can dive into it a little more.

    It is usually best to assume all addresses passed from the Non-Secure world are to be set NS (specifically), and pass physical (not virtual) addresses, and this is how most reliable SMC APIs are designed.

    Ta,

    Matt

Children
More questions in this forum