LayerscapeのトピックRe: During prototyping, can secured boot functionality be tested without blowing fuses?

During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Tue, 15 Oct 2019 05:14:10 GMT

Hi,

I would like to know a temporary way of provisioning SRKH Register(without blowing the fuses) and executing secured boot.

I am aware of SFP SRKH Mirror Registers being mapped to 0x01E80254 location onwards.

Question 1:

If we write to these mirror register will they have any effect on fuse array?

Question 2:

What is the endian-ness of SRKH Register?

Question 3:

During prototyping, can secured boot functionality be tested without blowing fuses?. If so, how?

Regards,

Rashmitha

chitra.amzarewale@utas.utc.com‌

shivesh.sood@collins.com‌

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Wed, 16 Oct 2019 08:08:33 GMT

Hello Rashmitha Ramesh Nair,

1. Only writing mirror registers will not affect fuse array.

2. SRKH Register is little endian on Layerscape platform.

3. During prototyping stage, the user needs to put the boot core in holdoff mode, setting BOOT_HO = 1 and enabled secure boot by SB_EN=1 in RCW. Then use CCS to connect to the target board to write SRKH mirror register without blowing fuses?

Platforms LS1021, LS1043, LS1046

ccs::config_server 0 10000
ccs::config_chain {<platform> dap sap2}
display ccs::get_config_chain
#Check Initial SNVS State and Value in SCRATCH Registers
ccs::display_mem <dap position> 0x1e90014 4 0 4
ccs::display_mem <dap position> 0x1ee0200 4 0 4
#Wrie the SRK Hash Value in Mirror Registers
ccs::write_mem <dap position> 0x1e80254 4 0 <SRKH1>
ccs::write_mem <dap position> 0x1e80258 4 0 <SRKH2>
ccs::write_mem <dap position> 0x1e8025c 4 0 <SRKH3>
ccs::write_mem <dap position> 0x1e80260 4 0 <SRKH4>
ccs::write_mem <dap position> 0x1e80264 4 0 <SRKH5>
ccs::write_mem <dap position> 0x1e80268 4 0 <SRKH6>
ccs::write_mem <dap position> 0x1e8026c 4 0 <SRKH7>
ccs::write_mem <dap position> 0x1e80270 4 0 <SRKH8>
#Get the Core Out of Boot Hold-Off
ccs::write_mem <dap position> 0x1ee00e4 4 0 0x00000001

Platforms LS1088, LS2088

ccs::config_chain {<platform> sap2}
display ccs::get_config_chain
puts "Entry RSP: "
ccs::write_mem 2 0x7 0x001000D0 0x4 0x0 0x800
set ::littleendian(2) 1
ccs::write_mem <sap position> 0x1e80254 4 0 <SRKH1>
ccs::write_mem <sap position> 0x1e80258 4 0 <SRKH2>
ccs::write_mem <sap position> 0x1e8025c 4 0 <SRKH3>
ccs::write_mem <sap position> 0x1e80260 4 0 <SRKH4>
ccs::write_mem <sap position> 0x1e80264 4 0 <SRKH5>
ccs::write_mem <sap position> 0x1e80268 4 0 <SRKH6>
ccs::write_mem <sap position> 0x1e8026c 4 0 <SRKH7>
ccs::write_mem <sap position> 0x1e80270 4 0 <SRKH8>
set ::littleendian(2) 0
puts "Exiting RSP: "
ccs::write_mem 2 0x7 0x001000D0 0x4 0x0 0x400

Please refer to the section "4.4.2 Running secure boot on target platforms" in LSDK 1906 user manual.

Please refer to Setting up Secure Boot on PBL Based Platforms in Prototype Stage

Thanks,

Yiping

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Thu, 17 Oct 2019 07:33:44 GMT

Hi yipingwang‌,

In CST,

First step is ./gen_keys xxxx ===>Which generates keys ===>srk.pri and srk.pub

Second step is ./uni_sign <loc>/input_uboot_qspi_secure ===>Which generates CSF Header ===>hdr_uboot.out

I am trying to understand what all are included in this .out file. From the comments displayed by CST, I can make out that digital signature is appended.

Question 1:

Does .out file include public key also?

Or should public key be loaded as a separate image?

Question 2:

What is the address of ESBC Pointer Register which points to CSF Header location? (FOR LS1046ARDB)

(SCRATCHRW1 - Pointer to ESBC Header (Primary Boot Image))

This is for 1st level authentication done by ISBC

I have a confusion if I should used DCFG Reg or SCFG Reg. There are SCRATCHRW Registers in both.

Thanks & Regards,

Rashmitha

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Fri, 18 Oct 2019 03:52:24 GMT

Hello Rashmitha,

1. There are RSA public and private key pairs, private keys are used to sign the images and public keys are keys are used to validate the image during ISBC and ESBC phase. Public keys are embedded in the header and the hash of SRK table is fused in SRKH register of SFP.

2. Please refer to the following in ls1043aqds/uboot_hdr_addr.rcw of RCW package. CSF Header is at 0x606c0000, the address of DCFG_CCSR_SCRATCHRW1 is at 1EE_0200.

.pbi
// Workaround for u-boot address.
write 0xee0200, 0x606c0000
.end

Thanks,

Yiping

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Fri, 18 Oct 2019 04:37:42 GMT

Hi Yiping,

That was very helpful. Thank you.

I changed SB_EN=1 and BOOT_HO=1 in RCW

I wrote SRKH Registers, loaded CSF Header and ESBC binary

Released the core by writing 0x0100 0000 to 0x01EE00E4

DCFG_CCSR_SCRATCHRW2 at 0x01EE0204 is having the value 0101 (Indicating mismatch)

Question 1:

QORIQ-SDK-2.0 documentations

Section 10.3.1.3 Pre-Boot Phase : talks about writing some LAWS

i) Are writing these LAWS mandatory? I have not included it in my execution currently.

ii) Could you please provide me the LAWS for LS1046ARDB (Along with purpose of each LAW, so that i can discard the ones that are not needed)

My inputs are:

(RCW_SRC=QSPI || CSF Header Location= 0x4070 0000 || ESBC Binary Location= 0x40100000)

iii) How and where should these LAWS be included?

Thanks,

Rashmitha

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Mon, 21 Oct 2019 06:10:17 GMT

Hello Rashmitha,

LAWs is only needed in PowerPC Architecture, no this concept in ARM architecture processor.

Thanks,

Yiping

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Tue, 22 Oct 2019 03:24:34 GMT

Thanks Yiping

I am facing an error because I did not fuse OTPMK (OTPMK_ZERO=1 in SFP HP Status Register)

I am trying to fuse OTPMK now,

But there is a mismatch in the value shown in AN5227 of SFP HP Status Register and the value on my board

As per AN5227, the value should be 88000900

My value is 8800AB00

SECURITY_CONFIG and SSM_STATE have mismatch

QORIQTRUST2.1UG_RevB does not provide explanation for SECURITY_CONFIG values.

What does SECURITY_CONFIG = 1010b (0xA) mean?

Regards,

Rashmitha

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Thu, 24 Oct 2019 09:12:33 GMT

Hello Ramesh Nair,

Please refer to the following for OTPMK key programming.

OTPMK[255:0] is:
1a4721b1d5371cf735e6975844932d9ce2f460b7aa7816a774e2aba90adca9a2
NAME | BITS | VALUE
_________|______________|____________
OTPMKR 0 | 255-224 | 1a4721b1
OTPMKR 1 | 223-192 | d5371cf7
OTPMKR 2 | 191-160 | 35e69758
OTPMKR 3 | 159-128 | 44932d9c
OTPMKR 4 | 127- 96 | e2f460b7
OTPMKR 5 | 95- 64 | aa7816a7
OTPMKR 6 | 63- 32 | 74e2aba9
OTPMKR 7 | 31- 0 | 0adca9a2

Write OTPMK registers to fuse array under CCS.
% config cc cwtap:10.81.116.21
% ccs::config_server 0 10000
% ccs::config_chain {ls1043a dap sap2}
% display ccs::get_config_chain

...

Chain Position 32: DAP
Chain Position 33: SAP2

Write OTPMK to mirror registers.
ccs::write_mem 32 0x1e80234 4 0 0x1a4721b1
ccs::write_mem 32 0x1e80238 4 0 0xd5371cf7

ccs::write_mem 32 0x1e8023c 4 0 0x35e69758
ccs::write_mem 32 0x1e80240 4 0 0x44932d9c
ccs::write_mem 32 0x1e80244 4 0 0xe2f460b7
ccs::write_mem 32 0x1e80248 4 0 0xaa7816a7
ccs::write_mem 32 0x1e8024c 4 0 0x74e2aba9
ccs::write_mem 32 0x1e80250 4 0 0x0adca9a2

Check OTPMK_ZERO and OTPMK_SYNDROME as 0 in SecMon_HP Status Register
% ccs::display_mem 32 0x1e90014 4 0 4
Check SFP_SVHESR no parity error.
% ccs::display_mem 32 0x1e80024 4 0 4
Permanently write OTPMK from the mirror registers into the fuse array
ccs::write_mem 32 0x1e80020 4 0 0x00000002

Thanks,

Yiping

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Fri, 25 Oct 2019 02:30:18 GMT

Hi yipingwang‌

I have fused OTPMK correctly without any errors. (For SRKH, I am using the "temporary write to mirror registers" option)

Now when I enable SB_EN =1 in RCW and try to execute Secure Boot

My application is running (prints on UART)

But

(i)SCRATCHRW2 Registers has 0x 41 03 (when I load SRKH in mirror register with %BE)

(ii) Same register has value 0x 40 03 (when I load SRKH in mirror register with %LE)

Question 1: I am not able to find the meaning of these error codes in ISBC ERROR CODES section. What do these errors indicate?

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

From LSDK 19.06, 6.1.2.10 ISBC error codes => Error handling in development environment (ITS = 0, SB_EN = 1)

I understand that the application runs if the error is NON-FATAL.

But even if i corrupt the hash or do not give hash in mirror registers, the application runs, bypassing secure-boot.

Question 2: What are the reasons for secure-boot bypass even when SB_EN=1 in RCW ?

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

Regards,

Rashmitha

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Wed, 30 Oct 2019 09:19:14 GMT

1. Please refer to section "6.1.1.8 Troubleshooting" in LSDK 19.06 document.

2. The behavior you see is correct, i.e system wouldn’t reset if there is mismatch in the hash but would continue when we do secure boot with SB_EN=1.

The system would get reset for this error , if your secure boot with ITS=1. (blowing fuse ITS)

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

rashmitharamesh — Mon, 04 Nov 2019 09:22:42 GMT

Hi yipingwang‌

Thank you for your reply

In development environment (ITS = 0, SB_EN = 1)

(ITS bit NOT fused)

Question 1: What are the conditions that should be checked to ensure secure boot is performed?

(Other than DCFG_CCSR_SCRATCHRW2 having a zero value)

Question 2: Should SecMon HP Status Register indicate 1101b = Trusted in SSM_STATE when secure boot is performed?

Regards,

Rashmitha

chitra.amzarewale@utas.utc.com‌

shivesh.sood@collins.com‌

Re: During prototyping, can secured boot functionality be tested without blowing fuses?

yipingwang — Tue, 05 Nov 2019 09:34:49 GMT

When secure is performed, secMon HP Status Register indicate 1101b = Trusted in SSM_STATE