Symptoms   Downloading a signed mage using UUU on i.MX 7D TO 1.3 (latest) silicon leads to authentication errors in an open chip and boot failure in closed chip.   Diagnosis   Reasoning behind this issue is that the TO1.3 has an Errata e11166 which disallows first 4K of the OCRAM memory region to be used for the bootable image. Since DCD is loaded at the start of OCRAM, the SDP download of the boot image fails.   Solution   Signing boot image While building the u-boot bootloader, the u-boot build log indicates the DCD address at which DCD will be downloaded, however, this address is incorrect and should be 0x911000 due to the Errata indicated above. $ cat u-boot-dtb.imx.log Image Type: Freescale IMX Boot Image Image Ver: 2 (i.MX53/6/7 compatible) Mode: DCD Data Size: 610400 Bytes = 596.09 KiB = 0.58 MiB Load Address: 877ff420 Entry Point: 87800000 HAB Blocks: 0x877ff400 0x00000000 0x00092c00 DCD Blocks: 0x00910000 0x0000002c 0x000001c4   When adding the DCD Block in CSF, make sure to fix the DCD address (if this is fixed in your u-boot version, ignore this step) CSF: [Authenticate Data] Verification index = 2 Blocks = 0x877FF400 0x000 0x81C00 "u-boot.bin", \ 0x00911000 0x2c 0x1C4 "u-boot.bin"   UUU command to download image: After the boot image is signed properly the image can be downloaded using UUU with following command: sudo ./uuu SDP: boot -f u-boot-signed.bin -dcdaddr 0x00911000   Using this command ensures the boot image is downloaded at the correct DCD address and thus the image can be authenticated properly.   This is also updated in UUU wiki:    

: 2 - Issue Description: 3 - Impact: 4 - Workaround: 4.1 Program eFuses at early boot phase: 4.2 - Disable CM4 boot 1 - Background: The HABv4 library locks certain SoC security-related features on closed devices when exiting the internal boot ROM. The features can be unlocked with "Unlock" commands inserted into the CSF signature, enabling users access to those features after boot. HABv4 locks the following OCOTP features by default in closed devices. Access to one of these features requires the CSF contain its specific "Unlock" command. Field Return: Lock Field Return activation. SRK Revocation: Lock SRK revocation feature. OCOTP SCS: Lock SCS register. OCOTP JTAG: Lock JTAG using SCS HAB_JDE bit. The i.MX7ULP has two independent HABv4 libraries running in each boot core, the unlock command procedure may vary according to the boot mode: Boot mode Instructions Single boot mode Refer to this document Dual boot mode Add unlock command in both CSF files (Cortex A7- CA7 and Cortex M4 -CM4) Low power boot mode Add unlock command in the M4 CSF file. Table 1. OCOTP Unlock procedure according to boot mode 2 - Issue Description: In single boot mode (CA7 core only) the CM4 image is authenticated by CA7 HAB library, hence the Unlock command can be only added in CA7 CSF. Even in single boot mode the CM4 ROM still executes as described below. 1 - CM4 is the first core to run after POR (regardless of boot mode configuration). 2 - CM4 ROM performs minimal system resource setup and retrieves the boot configuration. 3 - If single boot mode configured, the CM4 ROM enables the CA7 and begins polling the SIM0_DGO_GP7 register. 4 - CA7 ROM loads and authenticates its software image (U-Boot + CM4 SW) from the configured boot media (eMMC/SD). 5 - CA7 SW loads the CM4 SW to internal memory and writes the CM4 entry point address to the SIM0_DGO_GP7 register. 6 - CM4 ROM exits the polling routine and uses the supplied entry point address to continue with the CM4 boot process. In single boot mode, the CM4 ROM does not authenticate its own image. The CA7 ROM is expected to authenticate the CM4 SW image. Therefore the CM4 ROM does not process a CSF signature and is never exposed to any "Unlock" commands. This causes the CM4 ROM to always apply the default locks prior to exiting (after the entry point is supplied by the CA7 SW). This behavior will cause features exposed by an "Unlock" command in the boot image's CSF to be locked when the CM4 is released by the CA7 SW. Users can check OTP Controller Sticky Bit Register (0x410a6050) from U-Boot terminal to confirm SRK Revoke and/or Field Return fuses are locked: Fig 1.  OTP Controller Sticky Bit Register  => md 0x410a6050 1 410a6050: 0000001e 3 - Impact: All i.MX 7ULP B0 and B1 silicon revisions booting in single boot mode are impacted by this issue. Users should refer to workarounds below. 4 - Workaround: 4.1 Program eFuses at early boot phase: Our recommendation is to program all necessary fuses prior to setting CM4 entry point in SIM0_DGO_GP7 register. U-Boot is resuming CM4 ROM execution in mcore_early_load_and_boot() function in soc.c: int mcore_early_load_and_boot(void) { u32 *src_addr = (u32 *)&__firmware_image_start; u32 *dest_addr = (u32 *)TCML_BASE; /*TCML*/ u32 image_size = SZ_128K + SZ_64K; /* 192 KB*/ u32 pc = 0, tag = 0; memcpy(dest_addr, src_addr, image_size); /* Set GP register to tell the M4 rom the image entry */ /* We assume the M4 image has IVT head and padding which * should be same as the one programmed into QSPI flash */ tag = *(dest_addr + 1024); if (tag != 0x402000d1 && tag !=0x412000d1) return -1; pc = *(dest_addr + 1025); writel(pc, SIM0_RBASE + 0x70); /*GP7*/ return 0; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Users can modify code above and call fuse_prog() function available in mxc_ocotp.c: int fuse_prog(u32 bank, u32 word, u32 val)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This workaround is recommended for use cases that require the CM4 core image included in the boot image. 4.2 - Disable CM4 boot Alternatively, users can disable the CM4 boot by disabling the following U-Boot configuration. In this way users can use U-Boot fuse program as usual: - Defconfig:   CONFIG_IMX_M4_BIND = N - Kconfig:   ARM architecture -> Bind ULP M4 image to final u-boot Please note that CM4 may be needed by Linux Kernel to control power features. Users planning to use UUU to program SRK Revocation fuses must refer to this workaround. This issue does not compromise the i.MX security.

Background: There have been instances when HAB FAILURE events are seen when running hab_status in u-boot or parsing the HAB log in HAB persistent memory after loading a signed bootable image through Serial download mode in an open (non-secure)/closed (secure) chip. The HAB FAILURE event creates a dilemma of why a Closed (secure) chip boots even after the BootROM has generated HAB event related to authentication failure of the signed image. However that is not the case and is explained below.   Sample output of this issue:   => hab_status   Secure boot enabled   HAB Configuration: 0xcc, HAB State: 0x99   --------- HAB Event 1 ----------------- event data:         0xdb 0x00 0x08 0x42 0x33 0x22 0x0a 0x00   STS = HAB_FAILURE (0x33) RSN = HAB_INV_ADDRESS (0x22) CTX = HAB_CTX_AUTHENTICATE (0x0A) ENG = HAB_ENG_ANY (0x00)   Problem:   For the issue to be present in a i.MX chip, following are the requisites: i.MX chip in Open/Closed mode Internal fuse Boot mode or DIR_BT_DIS = 1 selected Recovery Boot medium enabled in Boot configuration   After POR, the chip boots up according to the Internal fuse boot configuration. For ease of understanding, let’s consider the Primary boot medium selected is SD/EMMC and Recovery boot medium as ECSPI. The chip tries to boot from SD/EMMC and fails. Then it tries to boot from the Recovery boot medium and finds the ECSPI boot device on the board (which does not contain a properly signed image). When HAB tries to authenticate this image, it leads to authentication failure and HAB FAILURE event occurs. The chip then falls back into Serial Download mode.   Thereafter, a properly signed boot image is loaded through SDP mode (using MFGtool/imx_usb_loader), the HAB in BootROM authenticates the image properly and boots the chip. When the HAB log is parsed to check for any HAB events, the HAB FAILURE events generated during the authentication attempt of Recovery boot medium, are displayed.   Solution: As the behavior seen in the chip in this scenario is by design, there is a way to determine whether the HAB FAILURE events seen after running the hab_status command in u-boot or parsing the HAB log in HAB persistent memory, are related to signed boot image loaded in SDP mode or not.   Parsing the BootROM log: The BootROM log in the chip records the boot flow in the chip and thus, it can be used to determine if the HAB FAILURE event was generated before or after entering the SDP mode.   For example: BootROM log in MX6QP in OCRAM:   0x00010002 <- Internal fuse 0x000200F0 <- Open chip 0x00030000 <- DIR_BT_DIS 0 0x00040000 <- BT_FUSE_SEL_VALUE 0 0x00050001 <- Sec Image select 0x00060001 <- SD boot selected 0x00070000 <- DEVICE_INIT_CALL 0x00070033 <- DEVICE_INIT_FAIL 0x00061004 <- ECSPI boot selected 0x00080000 <- DEVICE_READ_DATA_CALL 0x00000000 0x000800F0 <- DEVICE_READ_DATA_PASS 0x00090000 <- Authentication Status 0x000A2233 <- HAB_FAILURE 0x000C0000 <- SDP Entry   Here the HAB FAILURE event was generated before the chip goes into SDP mode, so it can be deduced that the HAB FAILURE event seen in the HAB log was due to the HAB failure while authenticating the Recovery boot medium instead of the image loaded through the SDP mode. P.S. - Please email me for any suggestions/changes to this document. P.P.S. - This document is up to date as of 08-20-2018

Background: The HABv4 Encrypted Boot feature available in CAAM supported devices adds an extra security operation to the bootloader sequence. It uses cryptographic techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used by unauthorized users. The Code Signing Tool (CST) automatically generates a random AES Data Encryption Key (DEK) when encrypting an image. This key is used for both encrypt and decrypt operations and should be present in the final image structure encapsulated by a CAAM blob, also know as DEK Blob. U-Boot supports the dek_blob command tool which is used to encapsulate DEKs generated by CST. The tool is based in a CAAM descriptor, users should provide the plain text key as input and receive a DEK blob which is unique per device. Additional information about encrypted boot can be found in the documents listed in the reference section of this document. Issue Description: For preparing a HABv4 encrypted boot image it's necessary to encapsulate the generated DEK in a blob. In all CAAM IPs versions after ERA 8 (please contact your local NXP representative for information) the blob generation function takes into consideration the Job Ring TrustZone ownership configuration field (JROWN_NS) which is available in Job Ring MID register (JRaMIDR_MS). The generated DEK blob can be only decapsulated by an environment running in the same JR configuration. The ROM code expects DEK blobs encapsulated by the Secure World environments which commonly have JROWN_NS = 0. As U-Boot in imx_v2018.03_4.14.78_1.0.0_ga release is running in Secure World we must set JROWN_NS=0 so the blobs generated by dek_blob tool can be decapsulated by the ROM code. Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to non-TrustZone") is incorrectly handling the JROWN_NS field and breaks HABv4 encrypted boot support in the certain i.MX devices. DEK blobs encapsulated by this environment cannot be decapsulated at ROM level and i.MX target fails to boot. Impacted devices and BSP releases: The following devices support CAAM ERA 8 or newer thus are impacted by this issue introduced in the imx_v2018.03_4.14.78_1.0.0_ga release branch. - i.MX 6UL - i.MX 7S - i.MX 7D - i.MX 7ULP All U-Boot releases after imx_v2018.03_4.14.98_2.0.0_ga have the proper fix in place, thus are not impacted. Please note: - This issue does not impact i.MX 6DQ, i.MX 6SDL, i.MX 6DQP and i.MX 6SX devices as TrustZone configuration is not considered in these devices (please contact your local NXP representative for information). - This issue does not impact older U-Boot GA releases, only imx_v2018.03_4.14.78_1.0.0_ga release branch is impacted. Workaround: Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to non-TrustZone") can be safely reverted as NXP BSP does not require all job-rings assigned to non-Secure world, users can use the command below based in imx_v2018.03_4.14.78_1.0.0_ga release branch: $ git revert 22191ac35344‍‍‍ Users can also refer to commit below on imx_v2018.03_4.14.98_2.0.0_ga release branch: MLK-21386 Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone" References: - U-Boot documentation, encrypted boot guide for i.MX6 and i.MX7 family devices. - AN12056: Encrypted Boot on HABv4 and CAAM Enabled Devices. This issue does not compromise the i.MX security.

Background: Certain i.MX device silicon revisions are affected by boot failures, when the boot device selected is External Interface Module (EIM) NOR or QSPI and the boot image targets internal OCRAM. The proposed workaround is for the boot image to not target OCRAM. These errata do not have any security implications. Impacted i.MX devices:   Silicon Rev ERR011121 ERR011112 Comments i.MX 6DualPlus/QuadPlus 1.1 Impacted* Not Impacted QSPI boot not supported i.MX 6Dual/Quad 1.6 Impacted* Not Impacted QSPI boot not supported i.MX 6DualLite/Solo 1.4 Impacted* Not Impacted QSPI boot not supported i.MX 6SoloX 1.4 Not Impacted Impacted* Both QSPI + EIM NOR impacted i.MX 6SoloLite 1.4 Impacted* Not Impacted  QSPI boot not supported i.MX 6UltraLite 1.2 Impacted* Impacted* Included in Latest Chip Errata Document i.MX 6ULL 1.1 Impacted* Not Impacted Included in Latest Chip Errata Document i.MX 7D/Solo 1.3 Not Impacted Impacted* Both QSPI + EIM NOR impacted *Only Silicon Revisions listed are impacted by this errata Errata: The following errata will be included in the next revisions of the respective Chip errata documents. ERR011121: System Boot: EIM NOR boot failure when the boot image targets OCRAM Description: A boot image corruption can result in a boot failure for a EIM NOR boot device under specific conditions as described below. The boot failure only occurs if all conditions below are satisfied. Conditions: There are four specific conditions that result in this boot failure: 1. i.MX device with the exact Silicon Revision listed in the impacted table above 2. A EIM NOR boot device is used 3. The device is in a security enabled configuration (SEC_CONFIG[1] eFUSE is programmed) 4. The boot image start address (specified in boot data) targets internal memory on Chip RAM (OCRAM) space. Projected Impact: EIM NOR  boot failure and possible entry into Serial Downloader mode. Workarounds: Since the boot failure only occurs when the boot image start address targets OCRAM space the recommended workarounds are for users to ensure the EIM NOR boot image runs from DDR or executes in place (XIP) and not target OCRAM. Proposed Solution: No fix planned. Linux BSP Status: Workaround not implemented in BSP: functionality where the erratum may manifest itself is not used.  Users will need to apply the proposed workaround when creating the boot image. _____________________________________________________________________________________________________________________ ERR011112: System Boot: QSPI/EIM NOR boot failure when the boot image targets OCRAM Description: A boot image corruption can result in a boot failure for a QSPI/EIM NOR boot device under specific conditions as described below. The boot failure only occurs if all conditions below are satisfied. Conditions: There are four specific conditions that result in this boot failure: 1. i.MX device with the exact Silicon Revision listed in the impacted table above 2. A QSPI/EIM NOR boot device is used 3. The device is in a security enabled configuration (SEC_CONFIG[1] eFUSE is programmed) 4. The boot image start address (specified in boot data) targets internal memory on Chip RAM (OCRAM) space Projected Impact: QSPI/EIM boot failure and possible entry into Serial Downloader mode. Workarounds: Since the boot failure only occurs when the boot image start address targets OCRAM space the recommended workarounds are for users to ensure the QSPI/EIM NOR boot image runs from DDR or execute in place (XIP) and not target OCRAM. Proposed Solution: No fix planned. Linux BSP Status: Workaround not implemented in BSP: functionality where the erratum may manifest itself is not used. Users will need to apply the proposed workaround when creating the boot image.

Introduction The Data Co-Processor (DCP) module available in i.MX 6ULZ, i.MX 6ULL, i.MX 6SLL and i.MX 6SL devices provide support for the general encryption and hashing functions. The DCP feature can be used by HAB to accelerate SHA-256 operations improving the image authentication time, it can be enabled by defining "Engine = DCP" in the CSF file header. Figure 1. Secure boot components Known Limitations For a correct usage of DCP engine the following limitations should be considered when signing images to be processed by DCP engine. 1 - Wrong cache handling in i.MX 6ULL and i.MX 6ULZ devices Due to an issue with the ROM code the HAB does not invalidate D-Cache when reading back the Hash generated by DCP, as the value processed by HAB is "wrong" the following HAB failure event is reported and target fails to boot in closed mode: --------- HAB Event 1 -----------------                                          event data:                                                                              0xdb 0x00 0x14 0x42 0x33 0x18 0xc0 0x00                                          0xca 0x00 0x0c 0x00 0x01 0xc5 0x1b 0x00                                          0x00 0x00 0x07 0xdc                                                      STS = HAB_FAILURE (0x33)                                                         RSN = HAB_INV_SIGNATURE (0x18)                                                   CTX = HAB_CTX_COMMAND (0xC0)                                                     ENG = HAB_ENG_ANY (0x00)     The DCP engine can still be used by HAB with d-cache disabled, this can be achieved by following the steps below: 1.1 - BootROM level D-cache can be disabled at ROM level by programming BT_MMU_DISABLE fuse (0x470[1]): => fuse prog 0 7 0x00000002 1.2 - U-Boot level The BT_MMU_DISABLE fuse only disables d-cache at BootROM level, U-Boot is re-enabling d-cache by default. The following command can be used to disable d-cache prior to authenticate Linux Kernel image: => dcache off Additional details can be found in chip errata "ERR010449 System Boot: HAB HAL routine hab_hal_invalidate_cache should invalidate L1/L2 D-cache, but did not in the ROM code". 2 - Authenticate data length must be 64 bytes aligned HAB requires chained hashing operations (operations involving multiple descriptors), every descriptor except the last must have a byte count that is a 16-word multiple (granularity of the hash algorithm). In case the authenticate data length is not 64 bytes multiple the following HAB Warning event is generated and SW implementation is used instead. --------- HAB Event 1 -----------------                                          event data:                                                                              0xdb 0x00 0x24 0x42 0x69 0x0a 0xc0 0x00                                          0xca 0x00 0x1c 0x00 0x02 0xc5 0x1b 0x00                                          0x00 0x00 0x0d 0x3c 0x87 0x7f 0xf4 0x00                                          0x00 0x00 0x03 0x0c 0x87 0x7f 0xf4 0x00                                          0x00 0x09 0x4b 0x1c                                                      STS = HAB_WARNING (0x69)                                                         RSN = HAB_UNS_ENGINE (0x0A)                                                      CTX = HAB_CTX_COMMAND (0xC0)                                                     ENG = HAB_ENG_ANY (0x00)   As only a HAB warning event is generated the target can still boot, please note that hashing operation in SW is slower than in DCP engine. This limitation only applies to users signing multiple blocks in authenticate data command, the example below can be processed by DCP. [Authenticate Data]     Verification index = 2     Blocks = 0x80800000 0x00000000 0x00000040 "zImage_pad_ivt.bin", \              0x80801000 0x00001000 0x006ee020 "zImage_pad_ivt.bin"             References Additional details about DCP block can be found in the respective SoC Security Reference Manual. Additional details can be found in the chip errata 

Description Patch Recovery image download steps Output log Finale Remarks Description The secure boot process in an i.MX8M device requires the initial boot image (SPL) to be signed which authenticates a signed FIT image by calling HAB API. For more details on i.MX8M secure boot, please refer AN4581 app note and u-boot docs. When the FIT image authentication fails in a closed device, the SPL hangs forever in an infinite loop which requires a system reset. Instead, the chip can be made to enter the serial download mode (SDP) so that a correctly signed FIT image can be downloaded again to continue the boot process. The chip can be entered into SDP mode from SPL using this in-built feature. Patch This patch adds the capability to move the chip into Serial Download Mode so that a new FIT image can be downloaded. diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index 2320ac9..ecfed9e 100644 --- a/arch/arm/mach-imx/spl.c +++ b/arch/arm/mach-imx/spl.c @@ -298,11 +298,15 @@ ulong board_spl_fit_size_align(ulong size) void board_spl_fit_post_load(ulong load_addr, size_t length) { uint32_t offset = length - CONFIG_CSF_SIZE; if (imx_hab_authenticate_image(load_addr, offset + IVT_SIZE + CSF_PAD_SIZE, offset)) { puts("spl: ERROR: image authentication unsuccessful\n"); - hang(); + g_dnl_unregister(); + //goto SDP mode from SPL + spl_sdp_load_image(NULL, NULL); } } diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c index d59ddc8..b1cdad0 100644 --- a/common/spl/spl_sdp.c +++ b/common/spl/spl_sdp.c @@ -18,7 +18,7 @@ void board_sdp_cleanup(void) board_usb_cleanup(CONFIG_SPL_SDP_USB_DEV, USB_INIT_DEVICE); } -static int spl_sdp_load_image(struct spl_image_info *spl_image, +int spl_sdp_load_image(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { int ret; diff --git a/include/spl.h b/include/spl.h index efb5833..f07e1b5 100644 --- a/include/spl.h +++ b/include/spl.h @@ -314,4 +314,8 @@ void spl_invoke_atf(struct spl_image_info *spl_image); * can implement 'board_return_to_bootrom'. */ void board_return_to_bootrom(void); + +int spl_sdp_load_image(struct spl_image_info *spl_image, + struct spl_boot_device *bootdev); #endif‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Recovery image download steps  Once the patch is implemented into SPL, the chip would directly go into SDP mode once the FIT image authentication fails. Following are the steps to download a new FIT image using UUU. UUU command to download new signed FIT: uuu SDPV: write -f flash.bin -skipspl UUU command to jump to  new FIT: uuu SDPV: jump Once done, the new FIT image will be downloaded and the authentication process will continue to authenticate the FIT image and continue the boot process. Output log   U-Boot SPL 2018.03-01236-g73af2fc-dirty (Nov 19 2019 - 14:01:) power_bd71837_init DDRINFO: start DRAM init DRAM PHY training for 3000MTS check ddr_pmu_train_imem code check ddr_pmu_train_imem code pass check ddr_pmu_train_dmem code check ddr_pmu_train_dmem code pass Training PASS DRAM PHY training for 400MTS check ddr_pmu_train_imem code check ddr_pmu_train_imem code pass check ddr_pmu_train_dmem code check ddr_pmu_train_dmem code pass Training PASS DRAM PHY training for 100MTS check ddr_pmu_train_imem code check ddr_pmu_train_imem code pass check ddr_pmu_train_dmem code check ddr_pmu_train_dmem code pass Training PASS DRAM PHY training for 3000MTS check ddr_pmu_train_imem code check ddr_pmu_train_imem code pass check ddr_pmu_train_dmem code check ddr_pmu_train_dmem code pass Training PASS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done Normal Boot Trying to boot from MMC1   Authenticate image from DDR location 0x401fcdc0... Error: CSF header command not found spl: ERROR:  image authentication unsuccessful <---------- FIT authentication fails SDP: initialize... <---------- SPL pushes chip in SDP mode SDP: handle requests... Downloading file of size 912688 to 0x40400000... done <---------- UUU command to download new signed FIT: “./uuu SDPV: write -f flash.bin -skipspl” Jumping to header at 0x40400000 <---------- UUU command to jump to  new FIT: “./uuu SDPV: jump” Header Tag is not an IMX image Found header at 0x4042a200   Authenticate image from DDR location 0x401fcdc0...     U-Boot 2018.03-01236-g73af2fc-dirty (Nov 19 2019 - 14:01:23 -)   CPU:   Freescale i.MX8MMQL rev1.0 1800 MHz (running at 1200 M) CPU:   Commercial temperature grade (0C to 95C) at 44C Reset cause: POR Model: FSL i.MX8MM EVK board DRAM:  2 GiB TCPC:  Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C1 0x] Power supply on USB2 TCPC:  Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C1 0x] MMC:   FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... *** Warning - bad CRC, using t   Failed (-5) No panel detected: default to MIPI2HDMI adv7535_init: Can't find device id=0x3d, on bus 1 Display: MIPI2HDMI (1920x1080) Video: 1920x1080x24 In:    serial Out:   serial Err:   serial   BuildInfo:   - ATF 1355c5d   - U-Boot 2018.03-01236-g73af2fc-dirty   switch to partitions #0, OK mmc0 is current device flash target is MMC:0 Net:   Error: ethernet@30be0000 address not set. No ethernet found. Fastboot: Normal Normal Boot Hit any key to stop autoboot:  0 u-boot=> hab_status   Secure boot disabled   HAB Configuration: 0xf0, HAB State: 0x66   --------- HAB Event 1 -----------------  <----------- HAB events created from initial FIT image auth failure and cannot be removed   event data:         0xdb 0x00 0x08 0x43 0x33 0x11 0xcf 0x00   STS = HAB_FAILURE (0x33) RSN = HAB_INV_CSF (0x11) CTX = HAB_CTX_CSF (0xCF) ENG = HAB_ENG_ANY (0x00)     --------- HAB Event 2 ----------------- event data:         0xdb 0x00 0x14 0x43 0x33 0x0c 0xa0 0x00         0x00 0x00 0x00 0x00 0x00 0x7e 0x0f 0xc0         0x00 0x00 0x00 0x20   STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00)     --------- HAB Event 3 ----------------- event data:         0xdb 0x00 0x14 0x43 0x33 0x0c 0xa0 0x00         0x00 0x00 0x00 0x00 0x00 0x7e 0x0f 0xe0         0x00 0x00 0x00 0x01   STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00)     --------- HAB Event 4 ----------------- event data:         0xdb 0x00 0x14 0x43 0x33 0x0c 0xa0 0x00         0x00 0x00 0x00 0x00 0x00 0x7e 0x10 0x00         0x00 0x00 0x00 0x04   STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00)   u-boot=> Finale Remarks Please note that the HAB events from the initial authentication failure of FIT image will still exist in the HAB persistent memory and thus will still be visible in the when hab_status command is called from u-boot or the HAB persistent memory is parsed using hab_log_parser.  The reason being that the HAB persistent memory only gets initialized/cleaned during system reset. The HAB events from the initial authentication failure can be ignored. P.S - This doc is updated as of 01/21/2020

1. Background 2. Issue description 2.1. Conditions to Reproduce 3. Impacted devices 4. Workarounds 5. Conclusion 1. Background SNVS is a companion module to the CAAM module and serves as the SOC's central reporting point for security-relevant events such as the success or failure of boot software validation and the detection of security threat events. This security event information determines whether the SoC (hardware and software) is in the proper state to allow the CAAM to use persistent and ephemeral secrets. Based on configuration fuses and configured bits within registers, SNVS is able to detect a variety of security violation inputs and perform the configured policy enforcement actions. SNVS incorporates both security and non-security functionality. In correlation with HAB states, the SNVS is in charge also with the global SSM (Security State Machine) of the chip.  By default, HPCOMR[NPSWA_EN] is enabled which means than any software can access privileged registers (e.g.: the SNVS LP / setting the RTC). In a secure closed configuration, HAB sets  HPCOMR[NPSWA_EN] on zero, so will let the access to privileged registers only to privileged software. 2. Issue description In a secured device (HAB closed), any access from non-secure world (aka the normal world) to privileged (TZ) world will fail. If NPSWA_EN bit is 1, the privileged registers can be read and written If NPSWA_EN bit is 0, the privileged registers can be read but can't be written If Linux is running in TZ secure world, the privileged register can be read and written in Linux kernel and Linux userspace From the experiments, the privileged software is the software running in TZ mode, i.e. AXI Port [NS] bit is used. NPSWA_EN bit enables only write rights to privileged registers because read is always enabled. Some examples: 1. RTC is failing in probe on secure boot fused devices. RTC driver fails to probe at Linux booting time. dmesg | grep rtc [ 1.468738] imx-drm display-subsystem: bound imx-dcss-crtc.0 (ops dcss_crtc_ops) [ 1.793324] snvs_rtc 30370000.snvs:snvs-rtc-lp: failed to enable rtc -110 [ 1.800219] snvs_rtc: probe of 30370000.snvs:snvs-rtc-lp failed with error -110 [ 3.414458] hctosys: unable to open rtc device (rtc0) 2.1. Conditions to Reproduce Secure boot enabled (Chip is closed - Security Configuration Enabled) - mandatory condition i.MX 8MQ - Boot Linux OS and the RTC driver will fail to probe in the kernel during kernel boot up i.MX 6/7 - Boot Linux OS with TEE enabled (this will make Linux OS booting in the non-secure world) and the rootfs will fail to be mounted (the same reason - configuring the SNVS LP privileged registers will fail). By default, i.MX 6/7 u-boot and Linux are considered booting in secure world by default. So accessing the SNVS privileged registers in HAB closed mode it's ok. By default, i.MX 8M/MN/Mini u-boot and Linux are considered booting in non-secure world by default. So accessing the SNVS privileged registers in HAB closed mode will fail. The difference comparing with legacy i.MX6/7 is introduced by ATF (Arm-Trusted-Firmware) from ARM which is used for booting the arm64 bits SoCs making the accesses from secure world (bootROM) to non-secure world (u-boot/Linux). 3. Impacted devices i.MX 6/7 i.MX 8M/MM/Nano Not impacted: i.MX 8/8X - SNVS handling is made via SECO API (SECO is considered secured every time because of the NXP Closed LC by default). 4. Workarounds From security access reasons, we didn't set NPSWA_EN=1 in SPL/u-boot when HAB is enabled but seems we have drivers in Linux that's requesting access to SNVS even when HAB is enabled. For all i.MX impacted families, the suggested patch below is recommended to be used in SPL/u-boot: +#define SNVS_HPCOMR 0x04 +#define SNVS_HPCOMR_NPSWA_EN BIT(31) + +void init_snvs(void) +{ + u32 val; + + /* Ensure SNVS HPCOMR sets NPSWA_EN to allow unpriv access to SNVS LP */ + val = readl(SNVS_BASE_ADDR + SNVS_HPCOMR); + val |= SNVS_HPCOMR_NPSWA_EN; + writel(val, SNVS_BASE_ADDR + SNVS_HPCOMR); +} 5. Conclusion Adopting the suggested patch in the u-boot/Linux will fix the issue identified in this document. This issue does not impact the Secure Boot flow.

1 - Background 2 - Issue Description 3 - Impact 4 - Workaround Changes required in the demo example build: 1 - Background In the i.MX 7ULP ROM, the HABv4 library interfaces with the SNVS module to guarantee the system security state. After closing the chip (Enabling Secure Configuration), HAB automatically transitions the SNVS Security State Machine (SSM) to a Trusted state and starts to monitor the SoC security system. The SNVS SSM can be only transitioned if HAB completes its security self-tests and no hardware security violations happened during the ROM boot process. Once SNVS SSM is in a Trusted state the HAB library is in charge to lock the following SNVS features, which can be enabled by adding an unlock command in CSF. - Disable LP Software Reset in SNVS_HPCOMR register. - Locks writes on Zeroisable Master Key. 2 - Issue Description The i.MX 7ULP has two independents HABv4 libraries running in each core, but only CA7 HAB library has the SNVS software support. As the HAB running in CM4 lacks the support of the  SNVS module, the SNVS SSM is not transitioned to a Trusted state in low power boot mode and thus remains in check state (b1001). As no SW support is available the SNVS locks mentioned above cannot be applied in this mode. 3 - Impact All i.MX 7ULP B0 and B1 silicon revisions are impacted by this issue. i.MX7ULP Low power boot mode users MUST apply the workaround below. i.MX 7ULP B2 addresses this issue in Silicon. 4 - Workaround Users can transition the SNVS SSM in CM4 software image after ROM boot. Here is an example of how the workaround can be implemented on a Hello World demo application. Changes required in the demo example build: Add SNVS LP and HP library header and C files in CMakeLists.txt file Include SNVS LP and HP header files in the Hello World demo application.  Add the following change in the Hello World demo application right after the initial setup. Please note this change should be implemented earliest in the application after CM4 bootup. BOARD_BootClockRUN(); BOARD_InitDebugConsole(); /* Get Boot Configuration */ uint32_t bt0_cfg = SMC_GetBootOptionConfig(MSMC0); bt0_cfg &= (BT0CFG_LPBOOT_MASK | BT0CFG_DUALBOOT_MASK); /* Check Boot mode is LP Boot Mode */ + if (bt0_cfg & BT0CFG_LPBOOT_MASK) { + /* Initialize SNVS */ + SNVS_LP_Init(SNVS); + + /* Transition SSM State */ + SNVS_LP_SSM_State_Transition(SNVS); + + /* Set Locks in SNVS HP Domain*/ + SNVS_HP_SetLocks(SNVS); + } + PRINTF("hello world.\r\n"); while (1) --‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Overview: The entry to the Field-Return configuration on a secure enabled device requires specific steps to be performed. On certain devices, the field-return configuration operates differently than currently described in the Security Reference Manual. The FIELD_RETURN fuse is protected by the FIELD_RETURN_LOCK sticky bit in the OCOTP_CTRL fuse controller. This requires the OCOTP module clock to be enabled to set the sticky bit Before leaving the boot ROM, the FIELD_RETURN_LOCK bit is set as long as the OCOTP clock has been enabled in the initial bootloader either via DCD or plugin method), so that the FIELD_RETURN fuse cannot be burned.  If the OCOTP module clock is not enabled then the FIELD RETURN behavior does not operate as described. In addition, if the device is configured in Serial Downloader Mode (SDP) the OCOTP module clock is not enabled on certain devices hence the Field Return Mode functionality does not operate as described. Expected Field Return behavior: Chip State OCOTP Clock FIELD RETURN Sticky Bit SRK REVOKE  Sticky Bit OCOTP_SW_STICKY value Comments Open (SEC_CONFIG[1] = 0) Disabled  Disabled  Disabled  0x18 No Unlock FIELD RETURN No Unlock SRK REVOKE Open (SEC_CONFIG[1] = 0) Enabled  Enabled  Disabled  0x1C No Unlock FIELD RETURN No Unlock SRK REVOKE Closed (SEC_CONFIG[1] = 1) Disabled  Disabled  Disabled  0x18 No Unlock FIELD RETURN No Unlock SRK REVOKE Closed (SEC_CONFIG[1] = 1) Enabled  Enabled  Enabled  0x1E No Unlock FIELD RETURN No Unlock SRK REVOKE Open (SEC_CONFIG[1] = 0) Disabled  Disabled  Disabled  0x18 Unlock FIELD RETURN Unlock SRK REVOKE Open (SEC_CONFIG[1] = 0) Enabled  Disabled  Disabled  0x18 Unlock FIELD RETURN Unlock SRK REVOKE Closed (SEC_CONFIG[1] = 1) Disabled  Disabled  Disabled  0x18 Unlock FIELD RETURN Unlock SRK REVOKE Closed (SEC_CONFIG[1] = 1) Enabled  Disabled  Disabled  0x18 Unlock FIELD RETURN Unlock SRK REVOKE Fixes: 1. Updated ROM: Certain devices such as i.MX 6SLL, i.MX 6UL, i.MX 7S/D, i.MX 8M, i.MX 8MM enable the FIELD RETURN and SRK REVOKE sticky bits in Serial Downloader Mode(SDP) boot mode. Future NPIs will incorporate similar functionality. 2. Software Patches to keep OCOTP Module Clocks Enabled U-boot patches developed to enable OCOTP clock in DCD/Plugin. All customers should ensure these patches are in place to ensure the clock to the OCOTP module is enabled. Patches in CodeAurora : 1. uboot-imx - i.MX U-Boot  2. uboot-imx - i.MX U-Boot   Security Implications As long as the OCOTP clock has been enabled, the FIELD RETURN functions as documented. In the development process where DCD/Plugin is not yet executed to enable OCOTP clock and JTAG is connected, it may be possible to program the FIELD RETURN fuse.

Background i.MX devices using High Assurance Boot (HAB) support Public Key Infrastructure (PKI) support using X.509v3 certificates.  The certificates support optional extensions that are used to provide additional attributes together with the public key and are either critical or non-critical. A certificate must be rejected if a critical extension cannot be handled properly while a non-critical extension may be ignored. The extensions can be seen as an additional protocol between a certificate issuer and an application. Issue A device configured in a security enabled configuration may not boot when using optional extendedKeyUsage attribute.The issue has been identified in the High Assurance Boot (HAB) during the parsing of a X.509 certificate in a security enabled configuration (SEC_CONFIG[1] eFUSE is programmed). The issue is with the MMU configuration in the ROM that is affecting the cache coherency when using this particular optional x.509 extension, preventing the device from booting. This issue does not have any security implications and is unrelated to the previous x509 vulnerability.   Impacted Devices All i.MX6 devices including the latest silicon revisions with the ROM updates are subject to this cache coherency limitation when using extendedKeyUsage  Only impacts devices configured in a security enabled mode. Designs not using security enabled mode are not affected. Workarounds The recommended workarounds is to not use this optional extendedKeyUsage attribute as it prevents the coherency issue If the customer insists on the use of extendedKeyUsage , then the other potential workaround is to disable MMU/cache during Boot. This  work around disables the MMU and will hence also prevent coherency issues on their device, however disabling the MMU/Cache does have some performance limitations - increasing the boot time Security Implications There are security implications if the certificate issuer wants to set the extendedKeyUsage extension as a critical extension. In this case, the certificate issuer wants to narrow down the possible contexts where the certificates will be usable, meaning it is very likely that the certificate will be rejected in a general context. There is a need to align the certificate issuer and the application.

[Background] We will meet boot failure issue in below conditions. 1) Hardware is i.MX6ULL 14x14 EVK. rework for NAND support. 2) Only enable secure boot (CONFIG_SECURE_BOOT) in NAND defconfig. In this condition, the boot data'size in IVT will increase with CSF size(0x4000). 3) Burn the flash without doing the CSF padding, thus the boot data size in IVT is larger than the acutal programming size. 4) Burn the flash with below command will program the primary image and seconday image into the NAND flash. --- $ kobs-ng init -x -v /run/media/mmcblk0p1/u-boot.imx-nand --- [Issue description] In above conditions, we will meet boot faliure when booting from NAND, and the system won't go into serial download mode. This is because the ROM will read the unprogrammed region based on the wrong boot data's size in the IVT, then it will trigger the ECC error, then the boot ROM will do the warm reset to boot the seconday boot image, but this warm reset is not correctly resetting the DDR controller that will impact the final DDR initialization when the DCD will be run for the second time by the secondary image, then the system will hang due to our DDR controller can't be initialized twice in i.MX6ULL.  Please see a similar issue in [1]. [Impacted devices] We only test the i.MX6ULL in open mode, other devices which is using DCD to intialize DDR may be impacted. If you meet this issue in other devices, please see the workaround described in [1] and report to us. [Workarounds] 1) For the boot faliure issue, two workarounds can be used.     (1) Padding the uboot image to align with the boot data's size in IVT.    (2) Manually correct the boot data's size to the actual uboot binary's size. 2) To let device go into serial download mode which should be the expected behaviour. Please check below commit for 6SLL. ---- commit 91f10877146407da5ef6670e406de4e044354c89 Author: Jason Liu <jason.hui.liu@nxp.com> Date:   Thu Jul 11 06:15:19 2019 +0800       imx6sll: redundant boot fix         Need clear the bit17 of CCDR, otherwise, system will hang up when     ROM run the DCD of second image. The reason due to ROM issue the     wdg_warm_reset when the authentication of the first image failed,     but it will also put the DDR into SR mode-the SDCLK to MMDC is off.     So, when ROM run the DCD of the second image, system will hang up.         In order to fix the issue, we simply clear the bit17 of CCDR in DCD     and restore it after u-boot boot up.         Signed-off-by: Jason Liu <jason.hui.liu@nxp.com> --- Or apply below patch, the system can go into serial download mode. ---- --- a/board/freescale/mx6ullevk/imximage.cfg +++ b/board/freescale/mx6ullevk/imximage.cfg @@ -50,7 +50,7 @@ CSF CONFIG_CSF_SIZE   *     Address   absolute address of the register   *     value     value to be stored in the register   */ - +DATA 4 0x020c4004 0x00000000 /* Enable all clocks */ DATA 4 0x020c4068 0xffffffff DATA 4 0x020c406c 0xffffffff diff --git a/board/freescale/mx6ullevk/mx6ullevk.c b/board/freescale/mx6ullevk/mx6ullevk.c index eeebcb3..9ee0549 100644 --- a/board/freescale/mx6ullevk/mx6ullevk.c +++ b/board/freescale/mx6ullevk/mx6ullevk.c @@ -488,7 +488,7 @@ int board_late_init(void) #ifdef CONFIG_CMD_BMODE         add_board_boot_modes(board_boot_modes); #endif - +       struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;         env_set("tee", "no"); #ifdef CONFIG_IMX_OPTEE         env_set("tee", "yes"); @@ -513,6 +513,8 @@ int board_late_init(void) #endif           set_wdog_reset((struct wdog_regs *)WDOG1_BASE_ADDR); +       /* restore to the default value */ +       writel(0x00020000, &ccm->ccdr);           return 0; } diff --git a/configs/mx6ull_14x14_evk_nand_defconfig b/configs/mx6ull_14x14_evk_nand_defconfig index 38f2dcf..b501fbc 100644 --- a/configs/mx6ull_14x14_evk_nand_defconfig +++ b/configs/mx6ull_14x14_evk_nand_defconfig @@ -47,3 +47,4 @@ CONFIG_DM_ETH=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_FEC_MXC=y +CONFIG_SECURE_BOOT=y ---- Thank you. [1] [BootROM/HABv4] - Redundant boot support is not triggered when first image's code is tampered  Best Regards, Frank

1 - Background: The USB download mode feature provides a means to load a software image to the target using the Serial Download Protocol (SDP). This feature is available on i.MX 7ULP CA7 ROM and is also used as a recovery mechanism after all possible boot paths have been exhausted. The image below is an example of serial downloader feature usage in SD/MMC Manufacture Mode, after failing all boot attempts the target enters in USB download mode enabling users to recover the device. Fig 1. SD/MMC Manufacture Mode boot flow 2 - Issue Description: The i.MX7ULP CA7 ROM code is forcing an SNVS Software violation prior to entering in USB recovery mode, this violation transitions the SNVS Security State Machine (SSM) from Trusted state to Soft fail state in HAB closed devices. Only ROM USB SDP failover mechanism is impacted by this issue, users can still use the serial download boot mode by setting BOOT_MODE = b01 (Please be aware of WDOG2 timeout issue) The following behaviors can be observed due to this issue. 2.1 - UUU boot failure and SNVS engine HAB event The following UUU timeout error is observed when trying to load an image after a SNVS Software violation: $ sudo ./uuu signed-uboot-sdp.imx uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.2.135-0-gacaf035 Success 0    Failure 1 1:12     1/ 2 [HID(W):LIBUSB_ERROR_TIMEOUT           ] SDP: boot -f "signed-uboot-sdp.imx"   As the SNVS SSM state machine is transitioned to soft fail the HABv4 library won't allow the target to boot up. Users can confirm this behavior by parsing HAB persistent memory region using the hab_log_parser tool available in CST package: ------------+----+------+----+------------------------------------------------- Event       |0xdb|0x002c|0x43| SRCE Field: 33 30 ee 1e             |    |      |    |             STS = HAB_FAILURE (0x33)             |    |      |    |             RSN = HAB_ENG_FAIL (0x30)             |    |      |    |             CTX = HAB_CTX_EXIT (0xEE)             |    |      |    |             ENG = HAB_ENG_SNVS (0x1e)             |    |      |    | Evt Data (hex):             |    |      |    |  00 00 00 00 80 00 b3 40 80 00 20 00 00 00 00 20             |    |      |    |  00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00             |    |      |    |  00 00 00 00 This issue can be observed in both single and dual boot modes. 2.2 - CM4 failure to boot in the absence of valid CA7 image The i.MX7ULP has two independents HABv4 libraries running in each core. Only CA7 ROM is able to transition the SSM but the CM4 ROM is still evaluating its state prior to boot the software image. An invalid CA7 image in boot media (No IVT or HW disconnected) would immediately cause a CA7 boot failure triggering a software violation. As the violation may happen before CM4 authentication completes the CM4 HAB library won't allow the target to boot up. Please note that this behavior can only happen in dual boot mode and may vary according to CM4 image and key length being used. 3 - Impacted Silicon: All i.MX 7ULP B0 and B1 silicon revisions using SDP recovery feature are impacted by this issue. Users setting BOOT_MODE = b01 (Serial Downloader) are not impacted by this issue. Please note that WDOG2 is enabled by default in i.MX7ULP B0 and B1 silicons, users should refer to the document below and understand the SDP boot limitations: i.MX 7ULP Cannot boot a Closed device via SDP  4 - Workarounds: No software workarounds were identified to address this issue. Users can still use the serial download feature by setting BOOT_MODE = b01. This issue does not compromise the i.MX security.

Background: CAAM MID (Or DID) registers can be configured to set TrustZone and master ownership to a certain CAAM module. Depending on the application, it may be necessary to set up an access policy so that the CAAM can be used by different masters and from the non-secure TrustZone world. Once the desired configuration is programed the register configuration can be locked (LDID) so no further changes can be made until reset. Issue Description: For devices, prior to HAB v4.4.0 the HAB code locks the Job-rings and DECO MID registers in the closed Secure configuration, the default configuration is assigning job rings and DECO to be used by the secure world only. In case the MID (or DID) registers are locked the bootloader cannot configure CAAM registers and the following errors may occur when trying to use CAAM from a non-secure world. - Kernel: [ 3.285187] caam_jr 30901000.jr0: failed to flush job ring 0 [ 3.293910] caam_jr: probe of 30901000.jr0 failed with error -5 [ 3.300025] caam_jr 30902000.jr1: failed to flush job ring 1 [ 3.305733] caam_jr: probe of 30902000.jr1 failed with error -5 [ 3.311837] caam_jr 30903000.jr2: failed to flush job ring 2 - U-Boot: RNG: Instantiation failed with error fffffffe RNG: Failed to instantiate RNG SEC0: RNG instantiation failed Workaround: If the application requires changes in CAAM MID (or DID) registers it is necessary to add the "Unlock CAAM MID" command into the CSF file. [Unlock]      Engine = CAAM      Features = MID This command should be added in the first image to boot in the device. Please note that the Unlock command is already included by default in the signed HDMI and DisplayPort firmware, so no need to add in i.MX 8MQ device in case HDMI is enabled. The current NXP BSP implementation expects the CAAM registers to be unlocked when configuring the CAAM to operate in the non-secure TrustZone world, this is the case for: - All i.MX 8MQ and i.MX 8MM Linux and Android users. - All i.MX 6, i.MX 7, and i.MX 7ULP OP-TEE users. Devices supporting HAB v4.4.0 and newer have the proper fix in place thus are not impacted. This issue does not compromise the i.MX security.

Background: On HAB closed part, before loading an image, ROM code will check the image target address and size to make sure it fits into valid memory range. The reason that ROM performs this check is that SD/EMMC data are read by block (512 Byte), and NAND are read by page. The maximum NAND page size supported by ROM is 16KB, and NAND driver puts its auxiliary buffer after the page read-to address + 16KB. Without this check, there could be a security hole when NAND driver loads Metadata from NAND page (the Metadata could be controlled by a hacker) to overwrite the memory that is reserved by ROM. So, this check is mandatory for NAND boot. Issue: If the image target address is OCRAM, ROM does this check to make sure it fits into OCRAM Free Space and also makes sure ROM's internal data will not be overwritten. While doing the check, ROM aligns up the image size with an alignment-up value which depends on the boot device. See table below for the alignment-up values.  Boot Device Alignment-up Value SD/EMMC 512 Byte NAND 18KB (if supported on this chip) No alignment-up will be done for other boot devices.  On 6UL 1.2, the OCRAM free space is 0x00907000~0x00917FFC, which is 0x10FFC in bytes. Thus, NAND boot will allow a maximum size of 0xD800 in bytes to download to the OCRAM free space. Workaround: For large size boot image with SD/EMMC and NAND boot, it is suggested that user loads the image to DDR rather than OCRAM. Affected Chips: i.MX Chip Tape Out i.MX6 DQP 1.1 i.MX6 DQ 1.6 i.MX6 SDL 1.4 i.MX6 SX 1.4 i.MX6 SL 1.4 i.MX6 SLL 1.1 i.MX6 UL 1.2 i.MX6 ULL 1.1 i.MX7 D 1.3 P.S. - Please email me for any suggestions/changes to this document. P.P.S. - This document is up to date as of 06-06-2018

Update October 16th 2018 i.MX High Assurance Boot Reference Code Signing Tool (REV 3.1.0) is now available and addresses all issues discussed in this thread. Users are requested to download this latest version instead. _________________________________________________________________________________________________________________________________ The purpose of this document is to provide a workaround for possible issues that can be found in the previous CST release v3.0.1.  - Compilation issues when using OpenSSL v.1.1.x OpenSSL v.1.1.x users may face the following error when trying to build the CST binary, this process is usually necessary for relinking the executable to include support for generating encrypted boot images: $ gcc -o cst -I ../hdr -L ../../../linux64/lib *.c -lfrontend -lcrypto adapt_layer_openssl.c: In function ‘gen_sig_data_ecdsa’: adapt_layer_openssl.c:551:36: error: dereferencing pointer to incomplete type ‘EVP_PKEY {aka struct evp_pkey_st}’          sign_bytes = ECDSA_size(key->pkey.ec);                                     ^ adapt_layer_openssl.c:580:28: error: dereferencing pointer to incomplete type ‘ECDSA_SIG {aka struct ECDSA_SIG_st}’          r = get_bn(sign_dec->r, &bn_bytes);                             ^ This issue impacts OpenSSL v.1.1.x users in both Windows and Linux OS, the current version can be checked by running the following command line: $ openssl version We recommend users to wait for next CST release. Alternatively it's possible to downgrade to OpenSSL v1.0.2, for more details please check link below: GitHub - openssl/openssl at OpenSSL_1_0_2g  - Encrypted boot images cannot boot up if generated with CST v3.0.1 Due to an issue with latest CST, the protocol constant tag for Decrypt Data command is not correctly defined in the CSF binary. CSF Example: [Decrypt Data]     Verification index = 0     Mac Bytes = 16     Blocks = 0x67800000 0xc00 0x74000 "u-boot-dtb.imx" CSF binary generated with CST v3.0.1: “CA 00 14 00 00 21 1D 00 00 00 0F 60 67 80 00 00 00 07 40 00” CSF binary generated with CST v2.3.3: “CA 00 14 00 00 A3 1D 00 00 00 0F 60 67 80 00 00 00 07 40 00”. The HAB code expects a HAB_PCL_AEAD (0xA3) tag and receiving an unknown (0x21) tag leads to a boot fail. From High Assurance Boot Version 4 API Document: Definition Value Description HAB_PCL_SRK 0x03 SRK certificate format HAB_PCL_X509 0x03 X.509v3 certificate format HAB_PCL_CMS 0xC5 CMS/PKCS#7 signature format HAB_PCL_BLOB 0xBB SHW-specific wrapped key format HAB_PCL_AEAD 0xA3 Proprietary AEAD MAC format This issue was introduced in CST v3.0.1, as a workaround we recommend users to use CST v2.3.3 until the next CST release. NOTE: The issues mentioned above does not compromise the i.MX security. Please let me know any suggestions/changes to this document. Last update: 07/31/2018

Problem: For i.MX6DL/Solo with latest silicon 1.4, system will hang when doing the "hab_rvt_authenticate_image" by using 2009.08 u-boot in SDP mode.   Background: 1) 2009.08 u-boot can work with rev 1.2 chip, while 2009.08 u-boot can't work with rev 1.4 chip when calling "hab_rvt_authenticate_image" in u-boot in SDP mode. 2) 2009.08 u-boot can't work with rev 1.4 chip, while 2017.03 u-boot can work with rev 1.4 chip when calling "hab_rvt_authenticate_image" in u-boot in SDP mode. 3) 2009.08 u-boot can't work with rev 1.4 chip when calling "hab_rvt_authenticate_image to authenticate "CAAM engine" image in uboot, but it is okay when authenticate "SW engine" image. 4)2009.08 u-boot can work with rev 1.4 chip when boot from NAND, but can't work with rev 1.4 chip in SDP mode. Investigation: By the debugger, we can see the code go into below dead-loop when hang. ------- clean_l2_inv_loop LDR r2,[r1,#0x7FC] TST r2,r4 BNE clean_l2_inv_loop <-dead loop here when the code can't really clean and invalidate the L2 cache by way ------- The root cause is related to the L2 cache and Boot Rom code(hab_hal_flush_cache) change. 1) u-boot 2009.08 disable the L2 cache while u-boot 2017.03 enable the L2 cache. 2) Boot Rom code "hab_hal_flush_cache" change in rev1.4. The logic in rev 1.4 is that the BootRom will clean L1 D cache and L2 Cache when we enable the L1 D cache and MMU in u-boot.  The logic in rev 1.2 is that the BootRom will clean L1 D cache and L2 Cache if we let BootROM to setup the MMU(pu_irom_mmu_enabled=true).  3)"hab_hal_flush_cache" function will be called when use CAAM to do the authentication. It will not be called when use SW to do the authentication.  Solution:    the solution for this topic can be Disable the L1 D cache before call RVT authenticate function in u-boot. Enable the L2 cache in 2009.08 u-boot.

1. Symptoms   Since Q1-25 BSP release, the usage of SPSDK for code signing has been introduced. The devices that support V2X images may face an issue while signing using the signing automation due to the fact the SPSDK release available during Q1-25 release is 2.6.x which does re-signing of V2X containers using OEM keys which are already signed by NXP. Affected Devices: i.MX 95 , i.MX 943, i.MX 8/8X Affected SPSDK version: Any version before SPSDK 3.0.0.   1. Solution   The issue has been fixed in SPSDK 3.0.0 onwards but automation has not been tested with SPSDK 3.0.0 onwards. Please apply/port the 0001-Pull-request-2506-feat-ahab-Skip-signing-of-V2X-cont.patch patch attached here, in versions before SPSDK 3.0.0 and rebuild the SPSDK tool. Now, the secure boot automation can be used to sign the affected devices' images properly.   2. Symptoms   Since Q1-25 BSP release, the usage of SPSDK for code signing has been introduced. Starting from SPSDK 3.0.0 the "signature_provider" has been renamed to "signer" . This will cause secure boot automation to fail.   2. Solution   Please use SPSDK version lower than 3.0.0 to rectify this issue. Eventually this change will be integrated into secure boot automation.   3. Symptoms   The image signing process fails for a boot image that is constructed with AHAB v2 container format. This is due to the fact that the nxp-cst-signer tool release v2.0 requires the container header version to be 0x00.  Affected Devices: i.MX 95 B0, i.MX 943. 3. Solution   The issue can be resolved by ignoring the version number check in nxp-cst-signer release v2.0. The corresponding patch 0001-Ignore-version-number-due-to-updated-contianer-forma.patch is attached to the post. This issue will be fixed and integrated in next release of nxp-cst-signer.    4. Symptoms   The imx-mkimage release lf-6.12.3-1.0.0 and SPSDK release 3.0.0 are known to have an issue with secure boot automation for images that are built with AHAB v2.0 container format due to the fact that neither the imx-mkimage tool correctly set the "Signature Format Header version" of the OEM container nor does the SPSDK modify this version when signing the image. SPSDK fails to sign the image due to this reason and reports invalid signature header version when verbose option (-vv) is enabled.   4. Solution   The patch "0001-add-signature-blk-version.patch" to resolve this issue in imx-mkimage is attached. The patch will be integrated in imx-mkimage Q3 '25 release.

Background: The High Assurance Boot (HABv4) feature available in i.MX & Vybrid family devices provides an option to extend the root of trust beyond the initial primary boot image. An Application Programming Interface (API) is provided by the on-chip ROM that allows the use of the HAB library to extend the root of trust and authenticate additional software images. When authenticating images using the hab_rvt.authenticate_image() API function the data caches can be used for a faster authentication. In devices listed below it is necessary to inform ROM code that caches are enabled prior to calling the hab_rvt.authenticate_image() API function. Otherwise, the ROM will not flush the caches when needed and the authentication may fail. Writing "0x1 to the PU_IROM_MMU_EN_VAR address prior to authenticating an image will notify ROM of the cache state. - i.MX 6Dual/6Quad - i.MX 6Solo/6DualLite - i.MX 6SoloLite The current U-Boot implementation is checking if the MMU is enabled and writing in PU_IROM_MMU_EN_VAR prior to authenticate an image, details can be found in hab.c code. More information about HAB API can be found in HABv4 API Reference Manual and in HABv4 RVT Guidelines and Recommendations application note (AN12263). Issue Description: The current address 0x00900a18 in hab.c code is not correct for i.MX 6SoloLite device, the correct address for MX6SL_PU_IROM_MMU_EN_VAR is 0x00901c60. As we are writing in the wrong address the ROM code is not flushing the caches when needed, and the following HAB event is observed in certain scenarios: --------- HAB Event 1 ----------------- event data:         0xdb 0x00 0x14 0x41 0x33 0x18 0xc0 0x00         0xca 0x00 0x0c 0x00 0x01 0xc5 0x00 0x00         0x00 0x00 0x07 0xe4 STS = HAB_FAILURE (0x33) RSN = HAB_INV_SIGNATURE (0x18) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) Impacted Devices: Only i.MX 6SoloLite (All silicon revisions) HAB API users with data cache enabled are impacted by this issue  The addresses provided for i.MX 6Dual/6Quad and i.MX 6Solo/6DualLite devices are correct hence are not impacted This issue does not impact i.MX 6SLL users or any other i.MX devices Impacted BSP releases: All U-Boot releases prior to imx_v2019.04_4.19.35_1.1.0 supporting HAB APIs are impacted by this issue. i.MX 6SoloLite HAB API users with data cache enabled must follow the recommendation in this document and update the source code to avoid a possible failure in the secure boot flow. Please note: - This issue does not impact the primary boot image authentication. - This issue does not impact users with data cache disabled. Software Patch: This issue can be fixed by updating the MX6SL_PU_IROM_MMU_EN_VAR address in source code, next U-Boot release planned for July 2019 will have a fix in place. In the meantime users can replace the wrong address 0x00900a18 by the correct one 0x00901c60. The following patch can be used as example. - U-Boot upstream project [External link]: [U-Boot] mx6sl: hab: Fix pu_irom_mmu_enabled address - Patchwork  Documentation Update Table 7.  in HABv4 RVT Guidelines and Recommendations application note (AN12263) will be updated in the next release to correct the PU_IROM_MMU_EN_VAR address for i.MX 6SoloLite The correct entry in Table 7 will be updated as below                                  Device PU_IROM_MMU_EN_VAR address i.MX 6SoloLite 0x00901C60 This issue does not compromise the i.MX security.