LS1021: SecMon state "not secure" when booting with BOOT_HO and SB_EN

[stefanhauser]

Hi,

I'm currently trying to implement secure boot on a ls1021a processor, booting from QSPI.

So far, burning OTPMK went fine and I changed RCW to set BOOT_HO and SB_EN.

I have generated the CSF headers for U-boot and changes PBL to let SCRATCHRW1 point to the CSF header for U-boot (this has also been validated with CodeWarrior tap after POR).

After POR, I check with CodeWarrior and can see that OTPMK was burned, but the SSM_STATE is already 0xB = Not Secure.

SCRATCHRW2 is still zero, so I assume that holding CPU0 in reset works.

Dump after POR:

Chain Position 17: DAP
Chain Position 18: SAP2
(bin) 72 % disp ccs::read_mem 18 0x1e90014 4 0 1
+0 +4 +8 +C
[0x01E90014] 8000AB00
(bin) 73 % disp ccs::read_mem 18 0x1ee0204 4 0 1
+0 +4 +8 +C
[0x01EE0204] 00000000

When releasing CPU0, SCRATCHRW2 changes to:

(bin) 75 % ccs::write_mem 18 0x1ee00e4 4 0 0x01000000
(bin) 76 % disp ccs::read_mem 18 0x1ee0204 4 0 1
+0 +4 +8 +C
[0x01EE0204] 01010000

0x101 means ERROR_STATE_NOT_CHECK, which would match my observations.

After POR I can see:

(bin) 79 % disp ccs::read_mem 18 0x1e90018 4 0 1
+0 +4 +8 +C
[0x01E90018] 80000008

So there is a security violation, but from what I can tell this is SEC_VIO3.

Any idea what SEC_VIO3 means and is this the reason that the sec mon is already in "non secure" mode even without releasing CPU0?

Is there anything else I can check? Can I disable that violation somehow to continue with implementing secure boot?

Thanks in advance,
Stefan

[stefanhauser · Accepted solution]

I figured this out myself, so if anyone stumbles across the same issue, this is what resolved the problem in my case:

As it seems, SEC_VIO3 is asserted as soon as TA_BB_TMP_DETECT_B is low.
Connecting this signal to TA_BB_VDD and connecting TA_TMP_DETECT_B to OVDD results in SSM_STATE = 0x9 (check) when booting with CPU0 in hold.

SEC_VIO3 bit in HPSVSR is also not asserted if both signals are high.

After programming the SRKH registers and releasing CPU0, I can see U-Boot starting and SSM_STATE is 0x0D (Trusted).

[yipingwang]

After Power on the target board, you need to use CCS connecting to the target board to write  SRKH key values into mirror registers then get the core out of the boot hold off state.

For details, please refer to page 9 in document https://community.nxp.com/t5/CodeWarrior-for-QorIQ-Knowledge/Secure-Boot-Debug-Configuration-for-LS1...

[stefanhauser]

Thanks @yipingwang for your help.

I totally forgot to mention that I'm writing the SRKH via CCS before releasing CPU0.

So I'm writing SRKH, then release the CPU0 and then the status in SCRATCHRW2 changes to ERROR_STATE_NOT_CHECK.

But as I wrote, directly after power on, the SSM_STATE is already 0xB (shouldn't this be 0x9 = CHECK?)

(bin) 72 % disp ccs::read_mem 18 0x1e90014 4 0 1
+0 +4 +8 +C
[0x01E90014] 8000AB00

My assumption was that the violation in HPSVSR is the problem that the SSM_STATE changes to 0xB.

The HPSVSR is:

(bin) 79 % disp ccs::read_mem 18 0x1e90018 4 0 1
+0 +4 +8 +C
[0x01E90018] 80000008

So there is a LP Security Violation, and bit SEC_VIO3 is set.

But I have no idea what SEC_VIO3 is. Does this have to do with the tamper detection?

TA_BB_TMP_DETECT, TA_TMP_DETECT and TA_BB_RTC are connected to ground on our board (external tamper detection is not needed). Does this cause any issues?