1 Reply Latest reply on Mar 28, 2018 6:00 AM by meenakshis_71

    How exchange Secure and non-secure access




      When we run PSoC 6 in Security mode, at first, we have to decide a secure access and a non-secure access domain with setting Address and Size in Protection context.

      Next, FW on CM0+ or CM4 exchange non-secure access for secure access. Then, the FW on CM4 or CM0+ run with secure mode and can access secure memory region.


      1. Although CM4 or CM0+ cannot has physical signal for secure/non-secure, how can SMPU in PSoC6 distinguish the accesses?


      2. Although FW on CM4 or CM0+ have to exchange the mode to access to secure region, how can we change the mode?

      I think we can use Cy_Prot_ConfigBusMaster API, but if CM4 is hacked and FW which use the API and runs with unwilling is updated on CM4, I do not have idea how we can protect the secure region.


      Best regards,

        • 1. Re: How exchange Secure and non-secure access

          Hello user_474444345,


          To your questions -


          1. The bit[1] of CYREG_PROT_SMPU_MSx_CTL register of CM4 (MS14_CTL) and CM0+(MS0_CTL) lets you switch between Secure/Non-secure access. This is also supported in the Cy_Prot_ConfigBusMaster API. When the bit is 0 for a particular master, the access is considered as Secure access from the master. Note that only CM0+, CM4 and Crypto block have the Secure access bit and DW0/DW1 do not support this access type through configuration. The DW0/DW1 inherit the secure access setting from the master that configures and enables it.


          2. Yes Cy_Prot_ConfigBusMaster API can be used to change the Secure/Non-secure access of a particular bus master. And yes if CM4 is hacked, it can very well use the API to configure itself in Secure mode and access/change secure region. That said, it is up to the application/user to protect the MSx_CTL registers from such access. Ideally, the MSx_CTL register should be modifiable only in Protection context 0 (this can be done by configuring a SMPU to protect the MSx_CTL registers). When you run a secure firmware, it is expected that the normal/user application runs in PC != 0 and only verified/validated/secure firmware is allowed to use PC = 0 (through a HW mechanism - Fixed/protected interrupt handler). As a result, the code that modifies the MSx_CTL is not a rogue code and is mostly an application defined secure code running in PC = 0.


          We will soon be releasing an application note detailing all these.



          Meenakshi Sundaram R