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

    How exchange Secure and non-secure access

    user_474444345
    user_474444345 Mar 21, 2018 11:04 PM

      Hello,

       

      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,

      • 129 Views
      • Tags:
        • 1. Re: How exchange Secure and non-secure access
          meenakshis_71
          meenakshis_71 Mar 28, 2018 6:00 AM (in response to user_474444345)

          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.

           

          Regards,

          Meenakshi Sundaram R