• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 473 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CSM Password Match Flow operation

Jerry Trantow
Intellectual 600 points

The documentation (http://www.ti.com/lit/ug/sprufb0d/sprufb0d.pdf 4.3.2 Password Match Flow) and the code examples for CSM_unsecure() seem to be incorrect for some cases.  Figure 12 indicates that reading all 0s indicates a permanently locked device, but won't the CsmPwl read as 0s when CSM_unsecure() runs from unsecure memory?  In this case, the CSM examples that I have seen will abort without writing the key (which would unlock the device).

  • 0
    TI__Guru* 93800 points

    Jerry Trantow said:
    The documentation (http://www.ti.com/lit/ug/sprufb0d/sprufb0d.pdf 4.3.2 Password Match Flow) and the code examples for CSM_unsecure() seem to be incorrect for some cases.  Figure 12 indicates that reading all 0s indicates a permanently locked device, but won't the CsmPwl read as 0s when CSM_unsecure() runs from unsecure memory?  In this case, the CSM examples that I have seen will abort without writing the key (which would unlock the device).

    Jerry,

    I agree this is a bit confusing.  Yes, indeed any read of the CSM password would give you back 0 until it unlocks - we call this a "dummy read" or a "fake read".  You are reading the password but will always get 0's no matter what the actual value is.    What is important is the *actual* value of the password.

    If the actual value is all 0xffff's then doing this "dummy read" will unlock the device and then you will be able to a real read of the password.

    If the actual value is all 0x0000's then no matter what you do you will never be able to unlock the device. 

    If the actual value is something other than all 0xFFFF or 0x0000 then when you do the dummy read, the actual value must match the password you provided. 

    Hope that clarifies.

    Cheers

    Lori

  • 0 in reply to Lori Heustess
    Intellectual 600 points

    Correct, it is confusing because the documentation isn't correct for all cases and some of the examples follow the documentation which cause them to fail under certain circumstances.  This mistake is only uncovered when the CSM unlock runs from unsecure memory.  I have also run across (wiki???) comments stating that the order of the write to the keys and the dummy read is arbitrary.  It seems the correct procedure is to write the keys and then do the dummy read.  This should work for all three password cases (all 1's, all 0's, arbitrary key) and executing from secure or unsecure.  Writing the keys first should allow proper identification of the key cases.

    This may seem like a small matter but mistakes like this can be costly if they brick an expensive device or critical application.

  • 0 in reply to Jerry Trantow
    Intellectual 600 points

    Just to clarify, the problem with the documentation flow chart is that a dummy read of all 0's doesn't necessarily indicate the device is permanently locked.  The routine might be executing from insecure memory and be locked.

  • 0 in reply to Jerry Trantow
    TI__Guru* 93800 points

    Jerry Trantow said:
    Correct, it is confusing because the documentation isn't correct for all cases and some of the examples follow the documentation which cause them to fail under certain circumstances.

    I will take a look at the documentation closer.  I'm not sure it isn't correct more than it isn't clear. 

    Jerry Trantow said:
    I have also run across (wiki???) comments stating that the order of the write to the keys and the dummy read is arbitrary.  It seems the correct procedure is to write the keys and then do the dummy read.

    It is actually arbitrary - but we have found writing to the keys and then doing the dummy read makes the most sense - I think our examples do it in this order.

    Jerry Trantow said:
    This may seem like a small matter but mistakes like this can be costly if they brick an expensive device or critical application.

    Only a password programmed with an actual value of all 0's will permanently lock the device. 

    Thank you for the feedback.

  • 0 in reply to Jerry Trantow
    TI__Guru* 93800 points

    Jerry Trantow said:

    Just to clarify, the problem with the documentation flow chart is that a dummy read of all 0's doesn't necessarily indicate the device is permanently locked.  The routine might be executing from insecure memory and be locked.

    Jerry,

    Thank you for the clarification.  I will feed this back to the team.

    Regards

    Lori