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.
解決済! 解決策の投稿を見る。
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.
Hello, I hope you are doing well.
According to the documentation, your understanding is correct.
Best regards.
To be clear, you are confirming our obervations, not our expectations, right?
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.
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
Hello,
Could you please share me the command and logs?
Best regards.
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