Testing LS1043Ardb Secure Boot without permanently blowing SRKH fuses

cancel
Showing results for 
Search instead for 
Did you mean: 

Testing LS1043Ardb Secure Boot without permanently blowing SRKH fuses

604 Views
Contributor III

My original question is on this forum under a related header, but it seems to have died. Perhaps this is because after someone posts to a question it falls into an "Assumed Answered" state regardless.

----------------------------------------------------------------------------------------------------------------------------------------------------------

Is there not a way to do this without making the change permanent? Writing to the fuses is fine. I just do not want to write to the fuses in such a way as to make it permanent (i.e. making our choice of key permanent).

The manual alludes to a method of doing this by writing to the SRKH shadow registers at boot time (pg 839, section 35.9.3.5). There is an additional step to transfer the mirror register values to the fuse array, but I was under the impression that without doing this final step then the values written to the mirror registers would suffice for secure boot testing.

How we can test secure boot by following the directions on page 8 of this document when we cannot access the SFP registers during secure boot (i.e. per 27.4.2.1 of the LS1043A reference manual)?

In other words, if we intend to boot in a secure way then we must at least configure with SBEN=1 in the RCW. However, according to section 27.4.2.1 we do not actually have read/write access to the SFP registers when booting in secure state. So, it seems that we cannot actually test the chain of trust using the value stored in the SRKH register without permanently writing your key hashes first before attempting a secure boot.

I understand how this would be a huge design flaw in the security architecture of this CPU if it allowed writing to the SRKH registers at boot time while attempting to boot in a secure mode, but it seems reasonable that this should work if the Intent to Secure (ITS) fuse was not set so it all may be tested before making the change permanent.

Labels (1)
0 Kudos
8 Replies

13 Views
NXP TechSupport
NXP TechSupport

You can _not_ do this from u-Boot. Secure boot requires a hard reset sequence which returns the mirror registers to their

reset states even if you initialized them before. Booting in core 0 holdoff and initializing registers via JTAG is essential.

0 Kudos

13 Views
NXP Employee
NXP Employee

True, for testing secure boot without permanently blowing SRKH fuses only ccs can be use. The other fuse programming can be done also from uboot.

Adrian

0 Kudos

13 Views
NXP Employee
NXP Employee

The endianness is similar. Now depending if you use uboot (big) or ccs dap/core access (little) or ccs sap access (big). Also, take care abou this: "Write SRKH fuse values into mirror registers. These values must be swapped before writing the

SRKH mirror registers."

This is because SFP_SRKHRn 0-31 >

SRKHR0: key hash bits 255-224

SRKHR1: key hash bits 223-192

SRKHR2: key hash bits 191-160

SRKHR3: key hash bits 159-128

SRKHR4: key hash bits 127-96

SRKHR5: key hash bits 95-64

SRKHR6: key hash bits 63-32

SRKHR7: key hash bits 31-0

Adrian

0 Kudos

13 Views
Contributor III

I think what you have written above might be a mistake. It seems that the first statement "SFP_SRKHRn 0-31" is true and reflects a little endian core. However, the second portion of your port seems to reflect big endianness. Although, I suppose you could also interpret the latter listed format as just informing of which bits align to which register.

So it is clear if anyone come across this and has the same questions, one programs the little endian running LS1043A as:

SRKHR0: key hash bits 244-255

SRKHR1: key hash bits 192-223

SRKHR2: key hash bits 160-191

SRKHR3: key hash bits 128-159

SRKHR4: key hash bits 96-127

SRKHR5: key hash bits 64-95

SRKHR6: key hash bits 32-63

SRKHR7: key hash bits 0-31

0 Kudos

13 Views
NXP Employee
NXP Employee

The steps from AN5227 are similar for LS1043. You can do all the settings from ccs or uboot (just be careful at endianness).

Adrian

0 Kudos

13 Views
Contributor III

From the reference manual it seemed to be quite similar; all the registers referenced in the appnote were identical for the LS1043A. It is really just the SRKH registers that I am concerned with at the moment. I can see from the AN5227 document that the target was big endian. To verify, what is the endianness of the LS1043A? The SDK available has two versions, one having a "-be" extension. That said, the default operation of the LS1043A is then little-endian?

0 Kudos

13 Views
NXP TechSupport
NXP TechSupport

AN5227 appnote that you referred talks about writing to mirror

registers via JTAG and provides steps to do that with CodeWarrior

debugger. As I mentioned  in my response to your earlier post,

there is no way to do it in PBL. It is not a security flaw because

JTAG access on production devices can be restricted by by fuses.

Note also that AN5227 is not directly applicable to LS1043A because

it is an ARM v8, not ARM v7 device and requires another CodeWarrior

suite. Details for your chip are currently under NDA, please create a

Support Case to receive additional information:

https://community.nxp.com/docs/DOC-329745

Regards,

Platon

0 Kudos

13 Views
Contributor III

Using a JTAG debugger was exactly how I was planning to do this, just not with the CodeWarrior TAP or development suite for now. I should have provided more information.

Could you provide the specific document for the LS1043A that must be requested under NDA?

0 Kudos