i.MX8 SSM behavior in OEM open lifecycle

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX8 SSM behavior in OEM open lifecycle

Jump to solution
618 Views
danielgloeckner
Contributor I

We are currently running our i.MX8 boards in the OEM open lifecycle to allow both signed and unsigned images to be booted.

Is our observation correct that the SSM stays in secure state and the same modified OTPMK is used by the CAAM even when an unsigned U-Boot is booted? We would have expected the SECO firmware to transition to soft fail/non-secure state unless U-Boot is correctly signed.

0 Kudos
1 Solution
548 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

Yes, I am confirming you observations and expectations.

In the OPEN configuration, a secure boot does not need to be successful to advance the ROM code execution flow so with the SSM in the Secure or Trusted states and the OTPMK available, test application keys should be used during development.

Only when using secure boot, SECO will transition to soft fail/non-secure state unless firmware is correctly signed. Also, If the SSM is in either the Trusted or Secure states when debug activity is detected then the SSM transitions to the Soft Fail state.

Best regards.

View solution in original post

0 Kudos
7 Replies
593 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello, I hope you are doing well.

According to the documentation, your understanding is correct.

Best regards.

0 Kudos
573 Views
danielgloeckner
Contributor I

To be clear, you are confirming our obervations, not our expectations, right?

0 Kudos
549 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

Yes, I am confirming you observations and expectations.

In the OPEN configuration, a secure boot does not need to be successful to advance the ROM code execution flow so with the SSM in the Secure or Trusted states and the OTPMK available, test application keys should be used during development.

Only when using secure boot, SECO will transition to soft fail/non-secure state unless firmware is correctly signed. Also, If the SSM is in either the Trusted or Secure states when debug activity is detected then the SSM transitions to the Soft Fail state.

Best regards.

0 Kudos
500 Views
danielgloeckner
Contributor I

Hello Jorge,

we moved one of our boards into OEM closed lifecycle. But using the U-Boot command ahab_cntrl to verify the signature of corrupt containers does not drop us into non-secure state. The SSM remains in secure state. I tried AHAB containers with various different defects and the SECO event log contained the events 0x0088F129, 0x0087F729 or 0x0087F029 after checking the containers.

How can we transition into non-secure state?

 

Best regards,
  Daniel

0 Kudos
458 Views
JorgeCas
NXP TechSupport
NXP TechSupport

Hello, 

Could you please share me the command and logs?

Best regards.

0 Kudos
387 Views
danielgloeckner
Contributor I

Hello Jorge,

the tests were done with an SCU firmware derived from version 1.15.0 of the porting kit and a U-Boot derived from tag rel_imx_5.4.70_2.3.2.

The AHAB container was loaded at address 0x98000000. I've changed the flags at offset 4 to cause authentication errors. The original flags byte was 0x02 for verification with OEM SRK 0. Using 0x00 (= unsigned container) instead resulted in

=> auth_cntr 0x98000000;ahab_status
Authenticate OS container at 0x98000000
sc_seco_authenticate: res:3
Authenticate container hdr failed, return -22
Lifecycle: 0x0080, OEM closed

SECO Event[0] = 0x0087F729
CMD = AHAB_AUTH_CONTAINER_REQ (0x87)
IND = Unknown Indicator (0xF7)

sc_seco_get_event: idx: 1, res:3

Using 0x12 (signed with OEM SRK 1) resulted in

=> auth_cntr 0x98000000;ahab_status
Authenticate OS container at 0x98000000
sc_seco_authenticate: res:11
Authenticate container hdr failed, return -5
sc_seco_authenticate: res:11
Error: release container failed!
Lifecycle: 0x0080, OEM closed

SECO Event[0] = 0x0087F029
CMD = AHAB_AUTH_CONTAINER_REQ (0x87)
IND = AHAB_BAD_SIGNATURE_IND (0xF0)

SECO Event[1] = 0x00890029 sc_seco_get_event: idx: 2, res:3

In a third test I changed an unimportand bit at the beginning of the kernel image. The result was

=> auth_cntr 0x98000000
Authenticate OS container at 0x98000000
sc_seco_authenticate: res:11
Authenticate img 0 failed, return -5
=> ahab_status
Lifecycle: 0x0080, OEM closed

SECO Event[0] = 0x0088F129
CMD = AHAB_VERIFY_IMAGE_REQ (0x88)
IND = AHAB_BAD_HASH_IND (0xF1)

sc_seco_get_event: idx: 1, res:3

In all three cases I proceeded to boot into Linux. Linux was still able to decrypt CAAM blobs that were created when booting without SECO events in OEM closed lifecycle. The CSTA register in Linux' CAAM job ring had the value 0x106, which tells me that the SSM was still in secure state.

Best regards,

  Daniel

0 Kudos
535 Views
danielgloeckner
Contributor I
Thank you for your answer.

So since the ROM rejects images which fail signature verification, the only way to execute code in non-secure state is by writing/modifying a bootloader to ignore the result of sc_seco_authenticate for the next boot stage?

Best regards,
Daniel
0 Kudos