TMS320F280049-Q1: DCSM: protect ram and peripherals register

1. If Zone2 code want to modify the value in zone1 ram and flash, it will return 0x00;

this is correct

2. If Zone2 code want to modify the value in zone1 ram and flash, it will be block; If you need to do that(such as OTA), you need to unlock the zone using function DCSM_unlockZone1CSM(&psCMDKey) before.

This is correct

3. Can DCSM protect the peripherals register? That means, if zone1 use PWM1, zone2 can't modify PWM1 related register.

No, DCSM cannot protect peripheral registers

4. Can DCSM realize the below function: For example, CPU can access LS0RAM, but DMA can't access LS0RAM, that seems it make sure only host can access specified memory range. If DCSM can't, is it exist other module in 280049 to realize this function?

I'm not sure I understand this question, are you asking whether the DMA can read or write secure memory?

Thank you,

Luke

Hi Luke,

Thank you for your reply!

Luke Jones said:

2. If Zone2 code want to modify the value in zone1 ram and flash, it will be block; If you need to do that(such as OTA), you need to unlock the zone using function DCSM_unlockZone1CSM(&psCMDKey) before.

This is correct

1. If I don't unlock the zone and modify the value in secure ram or flash, what will happen? This will be two situations.

A. This write will be ignored. If it will be ignored, do we have any test code or test report that can prove that data or program in secure areas will not be changed by code in unsecure areas?

B. This write will generate a interrupt or set a flag to notify the cpu that an illegal write has occurred, then cpu can take some measures.

2. What was the original intention of DCSM to design two zones? Can I just use zone1 and not use zone2? For example, I place ASIL B code in zone1 secure area and place common code in zone1 unsecure code, can I protect ASIL B code?

3. If I place ASIL B code in zone1 secure area and place common code in zone2 unsecure code, can I protect ASIL B code and can ASIL B code can read the data in zone2 unsecure area?

4. If I unlock the zone, it need to perform PFM flow, do we have testing report including how long does this flow will take? If I use correct password and wrong password, is the time required for this flow the same or different? If I use different wrong password(for example, right password is 0x1234567812345678, the wrong password is 0x123xxxxxxxxxxxxx and 0x1234xxxxxxxxxxxx) is the time required for this flow the same or different? customers afraid that the different PFM time will assist attackers in obtaining the correct password. 

5. In my understanding, the time of PFM flow is the time to excute the below code, right?

Best Regards

Shuqing Zhou (Sunny Zhou)

1. If I don't unlock the zone and modify the value in secure ram or flash, what will happen? This will be two situations.

I'm not sure whether you will get an error or if nothing will happen, either way, the write will be unsuccessful. I can test this on my side if needed.

2. What was the original intention of DCSM to design two zones? Can I just use zone1 and not use zone2? For example, I place ASIL B code in zone1 secure area and place common code in zone1 unsecure code, can I protect ASIL B code?

The purpose of two zones was to allow two developers to program code on the same device. For example, the primary developer may use a third party's code for some motor control algorithm but that third party could program their code in zone 2 to protect their proprietary code.

3. If I place ASIL B code in zone1 secure area and place common code in zone2 unsecure code, can I protect ASIL B code and can ASIL B code can read the data in zone2 unsecure area?

What do you mean "Zone 2 unsecure code"? Zone 2 code is secured by zone 2. Code in secure regions (zone 1 or zone 2) can read or write data in unsecure regions(unsecured by either zone)

4. If I unlock the zone, it need to perform PFM flow, do we have testing report including how long does this flow will take? If I use correct password and wrong password, is the time required for this flow the same or different? If I use different wrong password(for example, right password is 0x1234567812345678, the wrong password is 0x123xxxxxxxxxxxxx and 0x1234xxxxxxxxxxxx) is the time required for this flow the same or different? customers afraid that the different PFM time will assist attackers in obtaining the correct password. 

There should be no difference in the PMF timing. There is no significant delay between when the zone becomes unlocked  and when the final instruction of the PMF flow occurs.

5. In my understanding, the time of PFM flow is the time to excute the below code, right?

That's correct. If you're concerned about the timing of the password match  flow being different depending on if the unlock was successful or not, you may want to replace the driverlib function with your own custom code where the timing of the code is not dependent on a successful or unsuccessful unlock.

Thank you,

Luke

Hi Luke,

Luke Jones said:

I can test this on my side if needed.

Yes, customers need this test. And if you can share this test program, it will be better.

Best Regards

Shuqing Zhou (Sunny Zhou)

Hi Luke,

1. Could you give me the test project or test result in recent days? Customers are urgent and their project is in award process.

2. I have also test this using EVM board, but I meet some difficult:

A. When I unlock the area and load the program, the PC will stop in main();

B. Then I lock the area, the code will always run in Flash_setWaitstates(), could you help me figure out that why this will happen?

3. Z1_GRABSECT1R can configure the memory whether secure in zone1 or unsecure.

when I choose unsecure in syscfg, the value in register is 10, when I choose secured by this zone, the value in register is 01

So in what case the value of this register changes to 11?

I'm looking forward to your reply, thank you!

Best Regards

Shuqing Zhou (Sunny Zhou)

Hi Sunny Zhou,

By default the values in this register are "11" If the DCSM zone is locked and the register corresponding with a flash sector contains "11", that flash sector will be blocked, meaning no instruction fetches or data reads will be allowed from any source.

The flash API should return an error if it attempts to write or erase a secure region.

Are you running a particular software example from C2000Ware? Perhaps the flash_setWaitstates function is included in that software example and that function is not functioning properly when the device is secure.

Thank you,

Luke

Hi Luke,

1. Could you give me a definite me when the test program or result will provide to me? Customers required it urgently.

Luke Jones said:

I can test this on my side if needed.

2. Yes, I modify the code base on GPIO example from C2000Ware, the name of this example is gpio_ex3_interrupt.

Luke Jones said:

Are you running a particular software example from C2000Ware?

Best Regards

Shuqing Zhou (Sunny Zhou)

Hi Shuqing,

I may not be able to provide a test program until tomorrow as I'm busy with other things, however I can guarantee that any memory region that is secured by the DCSM cannot be read or written to by any code except code that is also secured by DCSM. For example, the flash API can only read or write secure memory if the flash API itself if stored in secure memory. For additional protection, you can designate a memory region as EXEONLY. This will block all data reads and writes from any source, only instruction fetches will be allowed.

I will try to provide some sort of test program demonstrating this by tomorrow but I don't see why this is required.

Thank you,

Luke