cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 6 MCU

Anonymous
Not applicable

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,

0 Likes
Reply
1 Solution
Employee

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

View solution in original post

0 Likes
Reply
1 Reply
Employee

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

View solution in original post

0 Likes
Reply
Top labels