i.MX Security

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

i.MX Security

Labels

Discussions

Sort by:
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.
View full article
Background: Issue Description: Root cause: Impacted Silicon Workarounds: Using UUU daemon mode: Background: The Watchdog Timer (WDOG) module provides a safety feature to ensure that software is executing as planned and that the CPU is not stuck in an infinite loop or executing unintended code. The i.MX 7ULP includes a secure WDOG (WDOG2) intended to monitor secure world code running on Cortex-A7. The WDOG2 is enabled by default during HW power on and its timeout is configured to 1024 counts. Since the ROM code is not refreshing or disabling WDOG2, the user software application must disable it within 1024 counts after reset. The WDOG2 counter clock is set to the Low Power Oscillator clock (1Khz) and a timeout occurs in 1 second. Issue Description: In HAB closed devices - (SECURITY_CONFIG = 1011b) the SNVS secure state machine (SSM) is set to Trusted state. In the case that the WDOG2 is not disabled on time an SNVS security violation is triggered transitioning the SNVS SSM to Soft Fail state. When booting via Serial Download Protocol (SDP) the software image must be loaded by the user before the WDOG2 is timing out in 1 second, which is not practical. The following UUU timeout error is observed when trying to load an image after WDOG2 timeout: $ 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"   Root cause: The SNVS security violation can be confirmed by parsing the HAB persistent memory region after failure: - Dump HAB persistent region using JTAG, addresses, and sizes are documented in AN12263. - Parse the HAB persistent region using the hab_log_parser tool available in the latest CST package available. The following HAB event is observed when trying to load an image in SNVS Soft Fail state: ------------+----+------+----+------------------------------------------------- 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 Please contact your local NXP representative for more details. Impacted Silicon Impacts all current silicon revisions of i.MX 7ULP Workarounds:  As WDOG2 cannot be disabled in ROM or fuses users must load an image prior to WDOG2 timeout.  In case an SNVS security violation still observed after boot please refer to the following document: [i.MX7ULP] WDOG2 SNVS security violation in a Closed Security Configuration   Using UUU daemon mode: UUU daemon mode can help to quickly load U-Boot through USB SDP, UUU daemon mode is able to detect USB OTG connection and load the image immediately: 1 - Set boot mode pins to SDP mode. 2 - Run UUU in daemon mode. ($ sudo ./uuu -d signed-uboot-sdp.imx) 3 - Reset target This issue does not compromise the i.MX security.
View full article
Background: ROM/HAB allocates certain memory region in Internal RAM (OCRAM) for HAB logs. This space is marked as reserved in Internal RAM memory map and must not be edited. This memory region is called HAB persistent memory. It contains certs, events and other HAB process related information. Description: HAB persistent memory is used by HAB to store audit logs i.e. logs of various events and status results generated from HAB library functions. HAB uses this memory region to search through existing events to report when requested through API call. HAB stores certificate information of the keys installed as reported in the CSF file. In u-boot when the hab_status command is called, HAB searches through this memory region for tags of events generated and parses them to a human-readable format.  Chipset HAB Persistent Memory Address Size i.MX RT1020 / RT1050 / RT1015 0x20201000 0xB80 i.MX6 S/DL/D/Q/DP/QP/UL/ULL/ULZ/SL/SLL/SX 0x904000 0xB80 i.MX7 S/D 0x9049C0 0xB80 i.MX7 ULP1 A7 B0 0x2F006840 0xB80 i.MX7 ULP1 M4 B0 0x20008040 0xB80 i.MX8 MQ (850D B0) 0x9061C0 0xB80 i.MX8 MQ (850D B1) 0x9081C0 0x1200 i.MX8 MM (845S A0) 0x908040 0xB80 i.MX8 MN (815S A0) 0x908040 0x1200 i.MX8 MP (865 A0) 0x90d040 0x1200 Vybrid F and R 0x3F077000 0xB80 i.MX 50 Family 0xF8004000 0x900 i.MX 53 Family 0x1FFE4000 0x900 i.MX 28 Family 0x0001A800 0x600 Reading HAB events: In order to check Events generated by HAB there are various methods that can be used: 1 - In u-boot, run hab_status command. Also, HAB persistent memory can be read and parsed to get these events (in case hab_status command isnt available) md.b <0xPERSISTENT_MEMORY_ADDR> <0xSIZE> 2. Connect JTAG and dump the HAB persistent memory region. 3. If chip is in Serial download mode due to Authentication failure, USB Serial download protocol can be used to read HAB persistent memory region. P.S. - Please email me for any suggestions/changes to this document. P.P.S. - This document is up to date as of 10-18-2018
View full article
Background i.MX 6/7/8MQ/8MM i.MX 8MNano/ 8MPlus Prepare&Program images to SD Card 1- Prepare primary and secondarybootloader 2- (i.MX 6/7/8MQ/8MM) Program primary, secondary bootloader and SIT table to SD 2- (i.MX 8MN/8MP) Program primary, secondary bootloader to SD and Secondary table offset to fuses 3- Enable secondary boot mode (i.MX 6/7/8MQ/8MM) Enable PERSISTENT_SECONDARY_BOOT bit in SRC register Corrupt IVT of the primary image Boot unsigned/improperly signed primary image in Closed chip Example i.MX 6Q SRC register Bootloader (u-boot) Known Issues Background The ROM supports the redundant boot for an expansion device (SD/eMMC). The primary or secondary image is selected, depending on the PERSIST_SECONDARY_BOOT setting. Both boot images need to be stored on the same flash (boot source).  In the scenario when either primary image is corrupted, or, the chip is in closed mode (Security Configuration Enabled) and there are failures during primary image authentication, the boot ROM turns on the PERSIST_SECONDARY_BOOT bit and performs a software reset. NOTE: In the Security Reference Manual/Reference Manual redundant boot or secondary boot are the same - meaning the ROM has the capability to choose which image to select from the 2 images located on the same flash device. NOTE: The i.MX 8/8X family of processors use a different container format for Secondary boot and is not discussed here. i.MX 6/7/8MQ/8MM If the PERSIST_SECONDARY_BOOT setting is 0, the boot ROM uses the address for the primary image. If the PERSIST_SECONDARY_BOOT setting is 1, the boot ROM reads the secondary image table from the address on the boot media and uses the address specified in the table for the secondary image.    Reserved (chipNum) Reserved (driveType) tag firstSectorNumber Reserved (sectorCount) Table 1. Secondary image table format   Where: The tag is used as an indication of the valid secondary image table. It must be 0x00112233 The firstSectorNumber is the first 512-byte sector number of the secondary image NOTE: The offset to the secondary image is calculated from the start of primary image in the flash and not the start of the flash. For example: In i.MX6, if the secondary image offset is expected to be 4KB (0x1000), then firstSectorNumber = (0x1000 - 0x400 (primary image offset in flash))/512 For the secondary image support, the primary image must reserve the space for the secondary image table. Refer to the figures below for the layout of the typical structure on an expansion device for the respective part. i.MX 6/7 i.MX 8MQ/8MM                                                                        i.MX 8MNano/ 8MPlus  In the i.MX 8MNano and i.MX 8MPlus processors, if booting from the device selected by the boot configuration pin or eFuse (Primary Device) fails, ROM will try to boot from the Secondary Image, the offset is relative to the beginning of the boot device (which is provisioned in the fuse IMG_CNTN_SET1_OFFSET). The fuse IMG_CNTN_SET1_OFFSET (0x490[22:19]) is defined as follows: The secondary boot is disabled if the fuse value is bigger than 10, n = fuse value bigger than 10. n == 0: Offset = 4MB n == 2: Offset = 1MB Others & n <= 10 : Offset = 1MB*2^n For the primary image offset and IVT offset details, please refer to the Primary image offset and IVT offset in the RM of the respective part. The secondary image offset is specified by fuses, please refer to the fuse map chapter in the RM of the respective part. Prepare & Program images to SD Card 1- Prepare primary and secondary bootloader Build two boot images with varying output to see the two different bootloaders boot up. Different timestamp Different output print etc.. Rename bootloaders as u-boot.primary and u-boot.secondary for i.MX6/7 and flash.primary and flash.secondary for i.MX 8M devices. On a closed device, another step will be utilized to sign the images. NOTE: The i.MX 8MQ (850D)  Boot ROM processes the HDMI Firmware only once out of POR. Thus, the secondary image should not contain the HDMI Firmware. 2- (i.MX 6/7/8MQ/8MM) Program primary, secondary bootloader and SIT table to SD The process described here programs the Secondary bootloader after the Primary bootloader at 0x1000 boundary.  The script to prepare and program the primary, secondary boot images and SIT table is attached. Analyze the primary image's size to align Prepare SIT table SIT Table: #Reserved (chipNum) = 0x00000000 #Reserved (driveType) = 0x00000000 #tag = 0x00112233 #firstSectorNumber = Primary align size/512 bytes #Reserved (sectorCount) = 0x00000000 firstSectorNumber will be calculated based on the primary image's align size Program SIT table to SD i.MX 6/7 sudo dd if=sit_table of=$dev bs=512 seek=1 count=20 && sync‍‍‍‍‍‍‍‍‍‍ i.MX 8MQ/8MM sudo dd if=sit_table of=$dev bs=512 seek=65 count=20 && sync‍‍‍‍‍‍‍‍‍‍ Program the primary image i.MX 6/7 sudo dd if=u-boot.primary of=$dev bs=512 seek=2 && sync‍‍‍‍‍‍‍‍‍‍ i.MX 8MQ/8MM sudo dd if=flash.primary of=$dev bs=1k seek=33 && sync‍‍‍‍‍‍‍‍‍‍ Program the secondary image i.MX 6/7 sudo dd if=u-boot.secondary of=$dev bs=512 seek=<(Primary image align size/ 512) + 2> && sync‍‍‍‍‍‍‍‍‍‍ i.MX 8MQ/8MM sudo dd if=flash.secondary of=$dev bs=1K seek=<(Primary image align size/ 1024) + 33> && sync‍‍‍‍‍‍‍‍‍‍ 2- (i.MX 8MN/8MP) Program primary, secondary bootloader to SD and Secondary table offset to fuses The process described here programs the Secondary bootloader at the offset specified by the user in IMG_CNTN_SET1_OFFSET fuse. The script to prepare and program the primary and secondary boot images is attached. Determine the offset at which Secondary image needs to be programmed in the boot device and program the IMG_CNTN_SET1_OFFSET fuse accordingly. For example: if offset required is 1MB then IMG_CNTN_SET1_OFFSET = n = 2 Run fuse command to program the fuse: fuse prog 2 1 00100000‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Calculate the offset in MB based on the fuse value selected (as per equation above). Let's call it Secondary_image_offset. Program primary image sudo dd if=flash.primary of=$dev bs=1k seek=32 && sync‍‍‍‍‍‍‍‍‍‍ Program secondary image sudo dd if=flash.secondary of=$dev bs=1K seek=<Secondary_image_offset/1024> && sync‍‍‍‍‍‍‍‍‍‍‍‍ 3- Enable secondary boot mode (i.MX 6/7/8MQ/8MM) Enable PERSISTENT_SECONDARY_BOOT bit in SRC register In u-boot, execute the following command mw.l <SRC_GPR10_addr> 0x40000000‍‍‍‍‍‍‍‍‍‍ Corrupt IVT of the primary image i.MX 6/7 sudo dd if=/dev/zero of=$dev bs=1 seek=1024 count=32 && sync‍‍‍‍‍‍‍‍‍‍ i.MX 8MQ/8MM sudo dd if=/dev/zero of=$dev bs=1 seek=33792 count=32 && sync‍‍‍‍‍‍‍‍‍‍ i.MX 8MN/8MP sudo dd if=/dev/zero of=$dev bs=1 seek=32768 count=32 && sync‍‍‍‍‍‍‍‍‍‍ Boot unsigned/improperly signed primary image in Closed chip Please read Known Issues section Example i.MX 6Q SRC register Bootloader (u-boot) U-Boot 2019.04-00695-g0ef6da0 (Apr 09 2020 - 12:23:09 -0500) CPU: Freescale i.MX6Q rev1.6 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) aC Reset cause: POR . . => md.l 20D8044 1 020d8044: 00000000 => mw.l 20D8044 40000000 => md.l 20D8044 1 020d8044: 40000000 => reset resetting ... U-Boot 2019.04-00695-g0ef6da0 (Apr 09 2020 - 12:41:38 -0500) CPU: Freescale i.MX6Q rev1.6 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) aC Reset cause: POR . .‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Known Issues 1- [BootROM/HABv4] - Redundant boot support is not triggered when the first image's code is tampered 
View full article
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) --‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
View full article
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.
View full article
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 left opened 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 Secure boot enabled (Chip is closed - Security Configuration Enabled) 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) 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.
View full article
[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
View full article
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.
View full article
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.
View full article
: 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.
View full article
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 
View full article
Issue: Patch description: Descriptor for parts with RNG version 4.0 or 4.1 or 4.2: Descriptor for parts with RNG version 4.3 or 4.4: Steps to implement these descriptors: Please read RNG self test issue on select i.MX device revisions first for an overview of the issue. Issue: In certain i.MX devices (open or closed) there have been reports of HAB warning events generated, even though the authentication has passed. If the reported HAB events are like the one from below, that means that there exists an issue with the RNG self test in HAB and the chip needs to run this test again post initial boot.       Event    |0xdb         |0x0024       |0x42       |      SRCE Field: 69 30 e1 1d              |             |             |           |             STS = HAB_WARNING   (0x69)              |             |             |           |             RSN = HAB_ENG_FAIL  (0x30)              |             |             |           |             CTX = HAB_CTX_ENTRY (0xE1)              |             |             |           |             ENG = HAB_ENG_CAAM  (0x1D)              |             |             |           |      Evt Data (hex):              |             |             |           |      00 08 00 02 40 00 36 06 55 55 00 03 00 00 00 00              |             |             |           |      00 00 00 00 00 00 00 00 00 00 01   Patch description: The resolution to the issue requires running a set of CAAM descriptors that implements CAVP test vectors. These tests are usually performed by HAB in Boot ROM. There are two sets of descriptors described here. There are two because parts with early RNG4s (4.0, 4.1, 4.2) have a 384-bit entropy register, while parts with RNG4 4.3 and 4.4 have the larger 512-bit entropy register. It can be seen that the load key command at line 2 of the second descriptor uses a longer key (the entropy in a known answer test). The RNG4 commands have been highlighted in green.  Basically, the test performs the operations of Instantiate, Generate,  Re-seed,  Generate, Uninstantiate. This follows the CAVP tests.   As the output is being written to memory, the comparison of the output with the known answer is being done by software.  That output is provided below, along with the descriptors, in this document.   Descriptor for parts with RNG version 4.0 or 4.1 or 4.2: rng_dsc[1] = {                0xb0800036, 0x04800010, 0x3c85a15b, 0x50a9d0b1,                                0x71a09fee, 0x2eecf20b, 0x02800020, 0xb267292e,                 0x85bf712d, 0xe85ff43a, 0xa716b7fb, 0xc40bb528,                 0x27b6f564, 0x8821cb5d, 0x9b5f6c26, 0x12a00020,                  0x0a20de17, 0x6529357e, 0x316277ab, 0x2846254e,                 0x34d23ba5, 0x6f5e9c32, 0x7abdc1bb, 0x0197a385,                 0x82500405, 0xa2000001, 0x10880004, 0x00000005,                 0x12820004, 0x00000020, 0x82500001, 0xa2000001,                 0x10880004, 0x40000045, 0x02800020, 0x8f389cc7,                 0xe7f7cbb0, 0x6bf2073d, 0xfc380b6d, 0xb22e9d1a,                 0xee64fcb7, 0xa2b48d49, 0xdf9bc3a4, 0x82500009,                 0xa2000001, 0x10880004, 0x00000005, 0x82500001,                 0x60340020, 0xFFFFFFFF, 0xa2000001, 0x10880004,                 0x00000005, 0x8250000d   } Human Readable Format:                          [00] B0800036       jobhdr: stidx->[00] len=54                  [01] 04800010          key: class2-keyreg len=16 imm            [02] 3C85A15B               key=[5ba1853cb1d0a950ee9fa0710bf2ec2e] [03] 50A9D0B1                                                      [04] 71A09FEE                                                     [05] 2EECF20B                                                     [06] 02800020          key: class1-keyreg len=32 imm              [07] B267292E               key=[2e2967b22d71bf853af45fe8fbb716a7 [08] 85BF712D                                                     [09] E85FF43A                                                     [10] A716B7FB                                                     [11] C40BB528                    28b50bc464f5b6275dcb2188266c5f9b] [12] 27B6F564                                                     [13] 8821CB5D                                                     [14] 9B5F6C26                                                     [15] 12A00020           ld: ccb1-ctx len=32 offs=0 imm            [16] 0A20DE17               data:[17de200a7e352965ab7762314e254628 [17] 6529357E                                                     [18] 316277AB                                                     [19] 2846254E                                                     [20] 34D23BA5                     a53bd234329c5e6fbbc1bd7a85a39701] [21] 6F5E9C32                                                      [22] 7ABDC1BB                                                       [23] 0197A385                                                      [24] 82500405    operation: cls1-op rng (SH0) instantiate PS test  [25] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[26] [26] 10880004           ld: ind-clrw len=4 offs=0 imm                                  [27] 00000005               clrw: clr_c1mode clr_c1datas                               [28] 12820004           ld: ccb1-datasz len=4 offs=0 imm                               [29] 00000020               data:0x00000020                                            [30] 82500001    operation: cls1-op rng (SH0) generate random test                     [31] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[32] [32] 10880004           ld: ind-clrw len=4 offs=0 imm                                  [33] 40000045               clrw: clr_c1mode clr_c1datas clr_c1key reset_ofifo         [34] 02800020          key: class1-keyreg len=32 imm                                    [35] 8F389CC7               key=[c79c388fb0cbf7e73d07f26b6d0b38fc                      [36] E7F7CBB0                                                                          [37] 6BF2073D                                                                           [38] FC380B6D                                                                          [39] B22E9D1A                    1a9d2eb2b7fc64ee498db4a2a4c39bdf]                     [40] EE64FCB7                                                                           [41] A2B48D49                                                                          [42] DF9BC3A4                                                                          [43] 82500009    operation: cls1-op rng (SH0) reseed test                              [44] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[45] [45] 10880004           ld: ind-clrw len=4 offs=0 imm                                  [46] 00000005               clrw: clr_c1mode clr_c1datas                               [47] 82500001    operation: cls1-op rng (SH0) generate random test                     [48] 60340020      fifostr: rng-ref len=32                                             [49] FFFFFFFF               ptr->@0xffffffff                                           [50] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[51] [51] 10880004           ld: ind-clrw len=4 offs=0 imm                                  [52] 00000005               clrw: clr_c1mode clr_c1datas                               [53] 8250000D    operation: cls1-op rng (SH0) uninstantiate (test) rng_result1[] = {  0x3a, 0xfe, 0x2c, 0x87, 0xcc, 0xb6, 0x44, 0x49,  0x19, 0x16, 0x9a, 0x74, 0xa1, 0x31, 0x8b, 0xef,  0xf4, 0x86, 0x0b, 0xb9, 0x5e, 0xee, 0xae, 0x91,  0x92, 0xf4, 0xa9, 0x8f, 0xb0, 0x37, 0x18, 0xa4 } Descriptor for parts with RNG version 4.3 or 4.4: rng_dsc2[] = {                0xb080003a, 0x04800020, 0x27b73130, 0x30b4b10f,                                        0x7c62b1ad, 0x77abe899, 0x67452301, 0xefcdab89,                                        0x98badcfe, 0x10325476, 0x02800020, 0x63f757cf,                                        0xb9165584, 0xc3c1b407, 0xcc4ce8ad, 0x1ffe8a58,                                        0xfb4fa893, 0xbb5f4af0, 0x3fb946a1, 0x12a00020,                                        0x56cbcaa5, 0xfff3adad, 0xe804dcbf, 0x9a900c71,                                        0xa42017e3, 0x826948e2, 0xd0cfeb3e, 0xaf1a136a,                                        0x82500405, 0xa2000001, 0x10880004, 0x00000005,                                        0x12820004, 0x00000020, 0x82500001, 0xa2000001,                                        0x10880004, 0x40000045, 0x02800020, 0x2e882f8a,                                        0xe929943e, 0x8132c0a8, 0x12037f90, 0x809fbd66,                                        0x8684ea04, 0x00cbafa7, 0x7b82d12a, 0x82500009,                                        0xa2000001, 0x10880004, 0x00000005, 0x82500001,                                        0x60340020, 0xFFFFFFFF, 0xa2000001, 0x10880004,                                        0x00000005, 0x8250000d  } Human Readable Format:                                                 [00] B080003A       jobhdr: stidx->[00] len=58                                         [01] 04800020          key: class2-keyreg len=32 imm                                   [02] 27B73130               key=[3031b7270fb1b430adb1627c99e8ab77                       [03] 30B4B10F                                                                          [04] 7C62B1AD                                                                          [05] 77ABE899                                                                          [06] 67452301                    0123456789abcdeffedcba9876543210]                     [07] EFCDAB89                                                                           [08] 98BADCFE [09] 10325476 [10] 02800020          key: class1-keyreg len=32 imm [11] 63F757CF               key=[cf57f763845516b907b4c1c3ade84ccc [12] B9165584 [13] C3C1B407 [14] CC4CE8AD [15] 1FFE8A58                    588afe1f93a84ffbf04a5fbba146b93f] [16] FB4FA893 [17] BB5F4AF0 [18] 3FB946A1 [19] 12A00020           ld: ccb1-ctx len=32 offs=0 imm [20] 56CBCAA5               data:[a5cacb56adadf3ffbfdc04e8710c909a [21] FFF3ADAD [22] E804DCBF [23] 9A900C71 [24] A42017E3                     e31720a4e24869823eebcfd06a131aaf] [25] 826948E2 [26] D0CFEB3E [27] AF1A136A [28] 82500405    operation: cls1-op rng (SH0) instantiate PS test [29] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[30] [30] 10880004           ld: ind-clrw len=4 offs=0 imm [31] 00000005               clrw: clr_c1mode clr_c1datas [32] 12820004           ld: ccb1-datasz len=4 offs=0 imm [33] 00000020               data:0x00000020 [34] 82500001    operation: cls1-op rng (SH0) generate random test [35] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[36] [36] 10880004           ld: ind-clrw len=4 offs=0 imm [37] 40000045               clrw: clr_c1mode clr_c1datas clr_c1key reset_ofifo [38] 02800020          key: class1-keyreg len=32 imm [39] 2E882F8A               key=[8a2f882e3e9429e9a8c03281907f0312 [40] E929943E [41] 8132C0A8 [42] 12037F90 [43] 809FBD66                    66bd9f8004ea8486a7afcb002ad1827b] [44] 8684EA04 [45] 00CBAFA7 [46] 7B82D12A [47] 82500009    operation: cls1-op rng (SH0) reseed test [48] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[49] [49] 10880004           ld: ind-clrw len=4 offs=0 imm [50] 00000005               clrw: clr_c1mode clr_c1datas [51] 82500001    operation: cls1-op rng (SH0) generate random test [52] 60340020      fifostr: rng-ref len=32 [53] FFFFFFFF               ptr->@0xffffffff [54] A2000001         jump: class1-done all-match[] always-jump offset=[01] local->[55] [55] 10880004           ld: ind-clrw len=4 offs=0 imm [56] 00000005               clrw: clr_c1mode clr_c1datas [57] 8250000D    operation: cls1-op rng (SH0) uninstantiate (test) rng_result2[] = {  0x76, 0x87, 0x66, 0x4e, 0xd8, 0x1d, 0x1f, 0x43,  0x76, 0x50, 0x85, 0x5d, 0x1e, 0x1d, 0x9d, 0x0f,  0x93, 0x75, 0x83, 0xff, 0x9a, 0x9b, 0x61, 0xa9,  0xa5, 0xeb, 0xa3, 0x28, 0x2a, 0x15, 0xc1, 0x57 } Steps to implement these descriptors: Running this test requires that RNG is not already instantiated using the same State Handle. If the RNG Self Test is being carried out using State Handle 0, then RNG should not be instantiated using State Handle 0 prior to running the test. u-boot currently instantiates RNG during boot so please ensure self test is run before instantiating RNG.  RNG self test descriptions provided here uses State Handle 0 to perform the self test. RNG instantiation with State Handle 0 can be left as is, if the RNG self test is run with State Handle 1.  Construct the right descriptor based on the CAAM ERA (CAAM CCBVID[31-16]), RNG VID (CAAM CHAVID[31-28]) and RNG REV (CAAM CRNR_LS[19-16]). If CAAM ERA is less than 8 and [RNG VID.RNG REV] < 4.3 then choose rng_dsc1 descriptors. Else choose rng_dsc2 descriptors. Make sure CAAM clock is enabled and initialize JR0. Construct the descriptors with the chosen descriptor set. Make sure to replace the output address of Known Answer Test result from 0xFFFFFFFF in the descriptor set to an un-used DDR destination address. Flush dcache of the region where descriptors are placed and the result will be placed. Run the descriptors using JR0. The result will be placed in the destination address from #3. Compare the result with the known respective result (rng_result1 or rng_result2) of the descriptor. If the comparison matches, the RNG self test has passed and RNG module can be used there onwards.
View full article
Background: The CAAM manufacturing protection feature provides a mechanism to authenticate the chip to the OEM's server. The manufacturing protection feature can be used to ensure that the chip:  Is a genuine NXP SoC  Is the correct device type and part number  Has been properly configured by means of fuses  Is running authenticated OEM software  Is currently in the secure or trusted mode The CAAM manufacturing protection feature is based on an ECC private key generated by the High Assurance Boot (HAB) code on every boot cycle. The Manufacturing Protection (MP) private key generation takes as input several fixed secrets and the MANUFACTURE_PROTECTION_KEY[255:0] being one of them in SoC fuses. Issue Description: On certain i.MX 8M and i.MX 8M Mini devices the MANUFACTURE_PROTECTION_KEY[255:0] fuses were incorrectly programmed at the NXP factory. During the MP private key generation, the CAAM block validates the inputs provided and fails as the MANUFACTURE_PROTECTION_KEY[255:0] provided is not a valid one. As the MPPubK-generation and MPSign CAAM functions depends on the result of MPPrivK-generation function the CAAM manufacturing protection feature cannot be used on the impacted devices. Details regarding manufacturing protection functions can be found in the section "Manufacturing-protection chip-authentication process" in i.MX 8M/i.MX 8MM security reference manuals (SRM). A preliminary application note is also available on request. Please note that in closed mode the CAAM MPPrivK-generation function can be only executed once in the same power-on session. Running a second time returns a CAAM error (0x40000481) undefined protocol command which is not related to the issue described in this document. Checking if your device is impacted: Customers can check if their device is impacted by following the 2 steps below: 1. Checking HAB events: The HAB code logs a warning event in the HAB persistent memory region after detecting a failure in the MP private key generation. This warning is logged independently regardless of whether HAB is enabled (SEC_CONFIG =1) or not. Customers can parse the HAB persistent memory region in order to get the warning events, more details in the  HAB Persistent memory in various MPU and MCU chipsets document. Impacted devices should report the event below: Event    | 0xdb | 0x0024 | 0x43 |  SRCE Field: 69 30 e1 1d             |         |             |         |             STS = HAB_WARNING (0x69)             |         |             |         |             RSN = HAB_ENG_FAIL (0x30)             |         |             |         |            CTX = HAB_CTX_ENTRY (0xE1)             |         |             |         |            ENG = HAB_ENG_CAAM (0x1d)             |         |             |         |  Evt Data (hex):             |         |             |         |   00 08 00 02 40 00 04 cc 55 55 00 0f 00 00 00 00             |         |             |         |   00 00 00 00 00 00 00 00 00 00 02 05 2. Checking the CAAM SCFGR register After running the MPPrivK-generation function the CAAM block stores in the CAAM SCFGR register the elliptic curve that was selected when the MPPrivK generation protocol was executed. Users can check the MPCURVE field [31:28] in the CAAM SCFGR register and on impacted devices this field will be 0. For more details, contact your local FAE. NOTE: In case your i.MX8MQ B0 device has an MPCURVE and still reporting HAB CAAM Warnings please refer to the document below: RNG self test errors on select i.MX device revisions  List of impacted devices: (Under development) i.MX 8MM: PIMX8MM6DVTLZAA 0N87W W8 D   i.MX 8MQ: - All i.MX 8MQ B0 devices with ON14W mask code are impacted. (e.g. PIMX8MQ6DVAJZAA ON14W SBAC1748C) - Some i.MX 8MQ B0 devices with 1N14W mask code are impacted, please check MPCURVE field [31:28] in the CAAM SCFGR register. - i.MX 8MQ B1 devices are not impacted. Workaround: No Software Workaround can be implemented. Customers planning to use the Manufacturing Protection feature should request for SoC's that have the correct fuse programming. Please Note: This issue does not impact the Secure Boot flow and does not compromise the i.MX security.
View full article
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.
View full article
  Background Issue Description Root Cause Projected Impact Impact Solution Software Patch CAAM address issue Silicon Fix     Background At each power-up, ROM /HAB code must test and instantiate the Random Number Generator (RNG) that is part of the CAAM. In order to perform this functionality, the HAB initiates a Self-test in the RNG using specific descriptors for the device.   Issue Description In certain i.MX devices (open or closed) HAB warning events can be generated, even though the authentication has passed. If the reported HAB events are like the one from below, that means that there exists an issue with the RNG self-test in HAB and the chip needs to run this test again post initial boot.       Event    |0xdb         |0x0024       |0x42       |      SRCE Field: 69 30 e1 1d              |             |             |           |             STS = HAB_WARNING   (0x69)              |             |             |           |             RSN = HAB_ENG_FAIL  (0x30)              |             |             |           |             CTX = HAB_CTX_ENTRY (0xE1)              |             |             |           |             ENG = HAB_ENG_CAAM  (0x1D)              |             |             |           |      Evt Data (hex):              |             |             |           |      00 08 00 02 40 00 36 06 55 55 00 03 00 00 00 00              |             |             |           |      00 00 00 00 00 00 00 00 00 00 01   Root Cause The descriptors used to run the RNG self-test in certain HAB versions of i.MX chips have been constructed incorrectly due to which the RNG self-test fails in CAAM.   Projected Impact This issue does not have any real impact on Secure Boot flow and does not compromise the security of the device. The reported warning still allows a device to be successfully configured in a Secure "CLOSED" configuration. The proposed software workaround should be applied before the RNG is utilized in the customer application. There is no method to remove the warning that occurs in the Boot ROM phase. After implementing the proposed workaround this warning can be ignored in further implementation of security.   Impact   Device Silicon Revision* RNG Self Test Issue i.MX 6DQPlus 1.1 Yes i.MX 6DQ 1.6 Yes i.MX 6DLS 1.4 Yes i.MX 6SX 1.4 Yes * Other Device Silicon Revisions are not impacted   Solution The correct set of descriptors have been identified and attached in this page, which can be run on the chip at the earliest boot stage in order to ensure that the RNG is functioning correctly before it is utilized for any crypto operations.   Software Patch Description of the patch for those who may have issues viewing the GPL licensed patch. RNG Self Test patch description    Patch has been created in u-boot 2016.03 version which can be utilized to run the RNG self-test command. This patch identifies the descriptors based on the CAAM version in the chip and determines which descriptor to run. The descriptors are executed in CAAM which results in a value that is compared with a known answer. If the Known Answer Test (KAT) passes, that means the RNG self-test has passed.   Please apply the patch from the following link:  https://portland.source.codeaurora.org/patches/external/imxsupport/uboot-imx/imx_v2016.03_4.1.15_2.0.0_ga/HAB-238-Run-RNG-self-test-for-impacted-i.MX-chips.zip    Troubleshoot: 1- CAAM address issue The CAAM address could resolve incorrectly when fetching CAAM version, RNG vid, and RNG rev values leading to incorrect descriptor selection and results. Following patch is necessary to fix this issue:   MLK-20893: imx: in_le32 out_le32 preprocessor casting issue with addresses involving math   The sec_in32 preprocessor is defined as follows in include/fsl_sec.h file: When address "a" is calculated using math for ex: addition of base address and an offset, then c   caam_ccbvid_reg = sec_in32(CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET) resolves to: caam_ccbvid_reg = in_le32((ulong *)(ulong)CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET) instead it should resolve to: caam_ccbvid_reg = in_le32((ulong *)(ulong)(CONFIG_SYS_FSL_SEC_ADDR + CAAM_CCBVID_OFFSET))   Thus add parenthesis around the address "a" so that however the address is calculated, the casti   Signed-off-by: Utkarsh Gupta <utkarsh.gupta@nxp.com> diff --git a/include/fsl_sec.h b/include/fsl_sec.h index cfb6782..71f4e82 100644 --- a/include/fsl_sec.h +++ b/include/fsl_sec.h @@ -14,8 +14,8 @@ #include <asm/io.h> #ifdef CONFIG_SYS_FSL_SEC_LE -#define sec_in32(a) in_le32((ulong *)(ulong)a) -#define sec_out32(a, v) out_le32((ulong *)(ulong)a, v) +#define sec_in32(a) in_le32((ulong *)(ulong)(a)) +#define sec_out32(a, v) out_le32((ulong *)(ulong)(a), v) #define sec_in16(a) in_le16(a) #define sec_clrbits32 clrbits_le32 #define sec_setbits32 setbits_le32 This fix is available from L4.14.98_2.0.0_GA release. 2- Job Ring TZ assignment issue:   While performing RNG Self Test on the affected silicons, it is possible to encounter the following issue: Error while running RNG self-test descriptor: -2 This issue is possibly occurring due to the Job Rings been assigned to a non-trustzone context as per the following patch in u-boot. This causes the RNG self test to fail to execute. https://github.com/u-boot/u-boot/commit/22191ac353445ad8fafc5a78aefcd94e78963041 If this patch exists in u-boot source then please revert the patch as per: https://github.com/u-boot/u-boot/commit/51f1357f3428819eeb254ab3f496c2803b36bbb3   Silicon Fix No silicon or ROM fixes are required. Future NPI's will ensure that the correct descriptors are provided to the RNG
View full article
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.
View full article
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
View full article
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.
View full article