i.MX8 SSM behavior in OEM open lifecycle

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX8 SSM behavior in OEM open lifecycle

ソリューションへジャンプ
1,297件の閲覧回数
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.

ラベル(1)
0 件の賞賛
返信
1 解決策
1,227件の閲覧回数
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 件の賞賛
返信
7 返答(返信)
1,272件の閲覧回数
JorgeCas
NXP TechSupport
NXP TechSupport

Hello, I hope you are doing well.

According to the documentation, your understanding is correct.

Best regards.

0 件の賞賛
返信
1,252件の閲覧回数
danielgloeckner
Contributor I

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

0 件の賞賛
返信
1,228件の閲覧回数
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 件の賞賛
返信
1,179件の閲覧回数
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 件の賞賛
返信
1,137件の閲覧回数
JorgeCas
NXP TechSupport
NXP TechSupport

Hello, 

Could you please share me the command and logs?

Best regards.

0 件の賞賛
返信
1,066件の閲覧回数
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 件の賞賛
返信
1,214件の閲覧回数
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 件の賞賛
返信