- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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