i.MX 8MQ SRK Revocation limitations in HAB Closed configuration

[#1]

• 1. Background
• 2. Issues description
• 2.1. No way to unlock the sticky bits when HDMI is disabled
• 2.2. The sticky bits are not locked up in the HAB closed mode and critical security features are lef...
• 2.3. Conditions to Reproduce
• 3. Impacted devices
• 3.1. Example of impacted device
• 4. Workarounds
• 5. Conclusion

1. Background

The i.MX SoC families support the revocation of SRKs. The SRK table generated by the srktool of the CST may contain up to four separate public keys. Only one SRK may be selected at boot time through an Install SRK CSF command. In the case where one or more of the first three SRKs are compromised, it is possible to revoke that SRK. For i.MX8MQ, there are 4 SRK revoke fuse bits that map to the first three SRK table indexes. An SRK key is revoked by burning the corresponding bit in the SRK_REVOKE [3:0] eFuse field

Header 1	Header 2	Header 3	Header 4	Header 5
Security eFuse	Definition	LOCK eFuse	Comment	Location
SRK_REVOKE[3:0]	Allows OEMs to manage root keys for HAB code signing by revoking selected keys.  Each bit corresponds to indices 0, 1 and 2 of the SRK table. Full support to revoke up to 4 SRK keys.	Protected by sticky bit in OCOTP controller: SRK_REVOKE_LOCK	0000 - No Revoke 0001 - Key 1 0010 - Key 2 0011 - Key 1 & 2 0100 - Key 3 0101 - Key 1 & 2 0110 - Key 2 & 3 0111 - Key 1, 2 & 3 1000 - Key 4 1001 - Key 1, 4 ... 1111 - All Keys	bank 9, word 3 - bits 0:3

In the Secure closed configuration, HAB, by default, sets the SRK_REVOKE_LOCK sticky bit in the OCOTP controller to write protect this eFuse field.

To instruct HAB not to lock the SRK_REVOKE field requires the use of the Unlock CSF command, with the command flag indicating to unlock the SRK_REVOKE field. Including this command in a CSF signature allows the SRK0 fuse to be blown by a trusted bootloader or runtime image. Below is an example CSF command that unlocks the SRK_REVOKE eFuse field, allowing U-Boot or a later stage to burn the fuse.

Below is an example CSF command that unlocks the SRK_REVOKE eFuse field, allowing U-Boot or a later stage to burn the fuse.

[Unlock]
Engine = OCOTP
Features = SRK_REVOKE

• Result: Leave SRK revocation unlocked.
  Clears the SRK_REVOKE_LOCK bit in Sticky bit Register (OCOTP_SW_STICKY -- 0xOCOTP_BASE + 0x50).
• Description: SRK revocation is locked by ROM and this Unlock command can be used to allow SRK revocation in the chip. Setting SRK revocation lock prevents later SW from burning SRK and Boot Image revocation fuses, as well as SNVS monotonic counter era fuses.

For more detailed information about CSF commands, refer to CST User’s Guide.

NOTE

The SRK Revocation does not modify the SRK Hash values, only SRK_REVOKE fuse has to be programmed.

Note that OCOTP_HW_OCOTP_SW_STICKY bit is not set in open configuration and you can read it.

u-boot=> md 0x30350050 1
30350050: 000007b4

The topics depicted by this doc are related also to Field Return and UID binding.

• UID selection: 
  
  Reading UID using fuse command in u-boot:
  
  

  => fuse read 0 1 8
  Reading bank 0:
  
  Word 0x00000000: 20220003 01234567 89abcdef 2002008d
  Word 0x00000004: 00620302 00000000 00000002 00000000

  
  Thus, UID to be mentioned in CSF as follows:
  

  [Unlock]
  Engine = OCOTP
  Features = FIELD RETURN
  UID = 0x67, 0x45, 0x23, 0x01, 0xef, 0xcd, 0xab, 0x89

• Able to set Field Return fuse and SRK Revoke fuse without Unlock command:
  
  During the BootROM bootup phase, the HAB checks for the Unlock commands for Field return and SRK revoke to set the corresponding sticky bit in OCOTP_SW_STICKY register. However, to do that the OCOTP clock should be enabled so that this module can be modified by HAB and the sticky bits can be set. If the OCOTP clock is not turned on, please make sure to enable the OCOTP clock in your design. Once enabled, when HAB/ROM boots up, it will set the Sticky bits and Field Return and SRK revoke must be locked out unless a corresponding Unlock command is present in the CSF of the boot image.

2. Issues description

There are 2 issues:

2.1. No way to unlock the sticky bits when HDMI is disabled

• If the HDMI is disabled via eFuses, then the HAB exit function is called and the sticky bits are set without having the possibility to "unlock" them. That's why it is required  to still keep the HDMI enabled via eFuses (only for the parts where possible)
• No SW fix

2.2. The sticky bits are not locked up in the HAB closed mode and critical security features are left opened 

• Reproduced only on B1 chips with HABv4.4.0

• A workaround in SPL is available to lock up the bits and clear Manufacturing Protection Private Key

  The sticky bits are locked in SPL for HAB closed mode. If you need them open for field return and SRK revoke, set CONFIG_SECURE_LOCKUP_WORKAROUND=n in defconfig.

  The FR (Field Return) dependency on UID is enforced by HAB. Once we are out of HAB space with unlocked sticky bits, there is no UID dependency. Enforcing it during secure boot implementation of SPL is possible by adding logic for UID along with config in the patch and also a validation logic for UID.

  BootROM/HAB is booting first in the boot flow chain and the HAB closed mode will never lock the sticky bits (users can just ignore the CSF unlock command ).

  The idea is to set CONFIG_SECURE_STICKY_BITS_LOCKUP=y if users need to have the sticky bit locked and put the same CONFIG on "n" if you want to have it unlocked

• Fixable by a Software patch - see Section 4 

The verbiage of the patch from chapter 4 does not take into account the scenario when HDMI is disabled (Issue #1). When HDMI is disabled, the option of setting the locks again is redundant, thus patch could also depend on the value of the HDMI disable fuse.

2.3. Conditions to Reproduce

1. Secure boot enabled (Chip is closed - Security Configuration Enabled)
2. For the 1st condition, HDMI needs to be disabled by eFuse (or HDMI FW is missing) (for B1 chips) or used a signed HDMI FW without the unlock command (for B0 chips)
3. For the 2nd condition, need to have B1 chips and HABv4.4.0 (and HDMI is still enabled via eFuses). The older parts are not impacted but need a modified HDMI FW with unlock command added.

3. Impacted devices

• All i.MX 8MQ - All devices and tape-outs with the conditions from section 2.3

Not impacted

• i.MX 8MQ - which doesn't meet the above conditions from section 2.3
• i.MX 8Mini, 8Nano, 8MPlus
• i.MX 8/8x 
• i.MX 6/7

3.1. Example of impacted device

Part number MIMX8MQ6CVAHZAB. from the datasheet this is rev 1.1 (B1) version.

fuse read 1 1

Reading bank 1:

Word 0x00000001: 08022000

The device B1 is closed and the HDMI is still enabled (HDCP is disabled) -> 1st issue is not applicable.

HAB version is 4.4.0 -> only 2nd issue is applicable.

4. Workarounds

Applicable only for the 2nd problem:

• Users should apply the attached patches directly to u-boot or ...
• Use directly u-boot imx_v2019.04 branch and included in Yocto BSP 4.19.35 1.1.0 release. CAF links for the patches below:
  d91e719 MLK-22836 imx8m: soc: Fix secure boot support for i.MX8MM and i.MX8MN targets
  443b88f MLK-22749 imx8mq: Add workaround to fix sticky bits lock up

5. Conclusion

Adopting the suggested patches in the u-boot will fix the issue identified in this document.

This issue does not impact the Secure Boot flow.