Overview A software vulnerability - CVE-2023-39902 has been identified in the U-Boot Secondary Program Loader (SPL) prior to version 2023.07 on select i.MX 8M family processors. Under certain conditions, a crafted Flattened Image Tree (FIT) Format structure can be used to overwrite SPL memory, allowing unauthenticated software to execute on the target leading to a privilege escalation.  Impacted devices NXP Devices Impacted Silicon Revisions i.MX 8M All i.MX 8M Nano All i.MX 8M Mini All i.MX 8M Plus All   Mitigation This section will cover possible mitigations identified by NXP and recommends users review this vulnerability against their specific use cases.  These mitigations may have varying applicability based on the customer’s designs and should be reviewed based on the established security policy that defines the security goals of the end product. It is up to the user to determine the impact (if any) to their products and take any necessary mitigation actions. U-Boot software patches to address this vulnerability(CVE-2023-39902) were incorporated in the NXP BSP GA Release  LF6.1.36_2.1.0 available for download on nxp.com. All subsequent NXP BSP GA software releases will incorporate the mitigations. To support the default hash and optional FDT signature solutions - four patches for u-boot (one patch only required for Android and one for a document update),  and two patches for imx-mkimage have been developed. Only one mitigation solution needs to be adopted if impacted.     Mitigation Patches Comments U-Boot 0746cfd LFU-573-1 imx8m: hab:Verify hash of FIT FDT structure Default Hash solution 07b6882 LFU-573-2 imx8m: hab:Verify optional FIT FDT signature Optional FIT DT signature solution 0001-MA-21597 check spl fit pointer before parsing it Only Required for Android 25fdc42 LFU-573-3 doc: imx8m: Update iMX8M secure boot and encrypted boot doc Documentation update imx-mkimage 2f2d426 LFU-573-1 imx8m: Generate hash of FIT FDT structure to SPL image Default Hash solution 5a0faef LFU-573-2 imx8m: Reserve new IVT+CSF for FIT FDT signature Optional FIT DT signature solution   Additional Information Customers authenticating additional software images from a bootloader not provided by an NXP BSP, should ensure correct authentication is being performed. For additional information, please contact your NXP Account Manager or Field Representative. You can also enter a technical support ticket and an NXP support engineer will contact you. Acknowledgment NXP would like to thank  Marek Vasut of DENX Software Engineering GmbH for the responsible disclosure. _____________________________________________________________________________ Please note this information is preliminary and subject to change. To the best of NXP's knowledge, the information contained herein is accurate and reliable as of the date of publication; however, NXP does not assume any liability for the accuracy and completeness of the information    

Overview The High Assurance Boot (HAB), 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. A vulnerability has been identified that impacts the use of this HAB library ROM API to extend the root of trust and authenticate additional software images. This vulnerability can be used to bypass signature checks and allow the execution of an un-authenticated software image. To prevent this vulnerability, simple checks in the customer application software are required, prior to calling the HAB library ROM API to authenticate additional software images. Impacted customers using the NXP BSP Reference software can apply two U-Boot software patches to address this vulnerability completely. Impact Only impacts devices configured in a security-enabled mode (SEC_CONFIG[1] eFUSE is programmed) Designs that are not using security-enabled mode are hence not impacted. All HAB versions up to 4.3.6 are impacted, only when using the HAB library ROM API to extend the root of trust and authenticate additional software images (e.g. Kernel) Customer applications that are not using this optional feature of the HAB library ROM API to authenticate additional software images are hence not impacted. This vulnerability does not impact the primary boot image Applications extending the root of trust that expose methods (local or remote) to update the product software image may be impacted Designs that prevent physical access to the device and do not utilize Over the Air (OTA) updates are not impacted. Software Mitigation Two U-Boot software patches to address this vulnerability were incorporated in the L4.9.88_2.0.0-ga software release. All subsequent NXP BSP GA software releases incorporate these checks in the U-Boot bootloader by default. Hence the mitigations are already incorporated in the latest NXP BSP releases and no further action is required. MLK-16703: HAB: Check if CSF is valid before authenticating image MLK-14945: HAB: Check if IVT valid before authenticating image Customers using U-Boot releases between L4.1.15_1.0.0-ga and L4.9.11_1.0.0-ga can refer to the following Yocto Patch releases. imx_v2017.03_4.9.11_1.0.0_ga imx_v2016.03_4.1.15_2.0.0_ga imx_v2015.04_4.1.15_1.0.0_ga For customers using older U-Boot Software releases patches are available on request. Code signing Tool Customers are recommended to use the latest version of the i.MX High Assurance Boot Reference Code Signing Tool - (CST) that has removed unsupported commands. Additional Information Refer to the Application Note - AN12263 - HABv4 RVT Guidelines & Recommendations and the HAB API Document (Included in the CST package) For more details, a Security Bulletin is available on the i.MX Security Portal for customers. For access or further information, please contact your NXP Field Support Representative or enter a support request.  _________________________________________________________________________ Please note this information is preliminary and subject to change. To the best of NXP's knowledge, the information contained herein is accurate and reliable as of the date of publication; however, NXP does not assume any liability for the accuracy and completeness of the information.

Topic Link Comments Secure Boot  Secure Boot with i.MX28 HAB Version 4 Applies to i.MX 28 Application Processor Secure boot in HABv4 enabled devices Applies to i.MX 6/7/8M Family of Application Processors Secure Boot in AHAB enabled devices Applies to i.MX 8/8X/8XLite Family of Application Processors Extended to support i.MX 8ULP and i.MX 93 Family of Application Processors Secure boot - step-by-step guides for both HAB and AHAB enabled devices The link may not be updated with the latest BSP release. Please switch to the latest BSP version for the updated guides. Encrypted Boot    Encrypted boot App Note for HABv4 and CAAM enabled devices Applies to i.MX 6/7/8M Family of Application Processors Encrypted boot - step-by-step Guides for HAB enabled devices Encrypted boot - step-by-step Guides for AHAB enabled devices Link may not be updated with the latest BSP release. Please switch to the latest BSP or the required version. Security Training               i.MX Security Training Various Security Training Workshops on older BSP releases.  NDA customers will need to request access from NXP. Secure Manufacturing Training Manufacturing Protection: Provision Sensitive Material in an Unsecure Environment Software Integrity and Data Confidentiality: Establishing Secure Boot and Chain of Trust on i.MX Processors This training explores the “Secure by Design” approach to software security for embedded systems using NXP i.MX processors - specifically, establishing secure boot and chain of trust  Securing Embedded Linux Devices: Pitfalls to Avoid This training session explores the proven best practices for designing and maintaining secure products, common security pitfalls & tips for hardening embedded Linux devices. Linux Kernel Security: Overview of Security Features and Hardening This training session explores how the Linux kernel's configuration can be strengthened to protect against security exploits. Essential Security Considerations for Edge Applications This training session introduces key features of embedded security, from secure boot and debug to lifecycle management. Code Signing Tool Latest Code Signing Tool Code Signing Tool (CST) package with complete source code and documentation. Using Code Signing Tool with Hardware Security Module Hardware Security Module backend exposed to extend the usage of CST with external HSM Secure Debug  Secure Debug on devices with JTAG controller Applies to i.MX 6/7/8M Family of Application Processors Secure Debug on devices with JTAG controller and Authenticated Debug Module (ADM) Applies to i.MX 8/8x Family of Application Processors Extending the Root of Trust HABv4 RVT guidelines and recommendations  The HAB API allows the use of the HAB library to extend the root of trust and authenticate additional software images. This document describes system considerations when planning to make use of this API. HAB Persistent memory  HABv4 persistent memory address regions for various i.MX Application Processors HAB persistent memory is used by HAB to store logs. The base address and size are provided for each processor. OP-TEE   i.MX Porting Guide - Configuring OP-TEE chapter Guide to OPTEE enablement on various i.MX devices can be requested for customers under NDA Getting Started with OP-TEE on i.MX Processors Webinar - Getting started with trusted execution environments (TEE) - OPTEE enablement on various i.MX devices  Secure  Updates Secure Over the Air Updates Source Code  ______________________________   Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini & i.MX 93 ______________________________  Secure Software Updates: Designing Ota Updates For Secure Embedded Linux Systems Secure Over-the-Air Prototype for Linux Using CAAM and Mender or SWUpdate ______________________________ SWUpdate is a Linux Update agent to provide an efficient and safe way to update an embedded Linux system. SWUpdate supports local and OTA updates, & multiple update strategies ___________________________ Webinar on Field updates of the software with Over-the-Air (OTA) Incremental updates, full OS updates. Signing of packages and update images, server authentication and other key considerations for securely deploying updates. Secure Manufacturing Manufacturing Protection App Note   Manufacturing Protection Verification tool   Secure Manufacturing Training Guidance to secure manufacturing in supported i.MX devices. Reference verification tool provided to authorize products with this feature enabled. Manufacturing Protection: Training on how to provision Sensitive Material in an Unsecure Environment Public Key Cryptography using CAAM Secure Key Strengthening Public Key Cryptography using CAAM Secure Key Source Code Leveraging the i.MX CAAM module to ensure the transfer of confidential data upon insecure channels using ECDSA secure keys Secure Storage i.MX Encrypted Storage Using CAAM Secure Keys Understanding SECO Secure Storage and Non-Volatile Memory Management  This document provides steps to run storage encryption at the block level using DM-Crypt taking advantage of the secure key feature. This document describes some of the key concepts related to the Security Controller secure storage and non-volatile memory management.  Securing Data Demo Application to Generate Red/Black Blobs Using CAAM and Encrypt/Decrypt Data Source Code This document provides instructions and steps on how to set up and run a demo application to generate both red and black key blobs and use them to encrypt and decrypt data. Enhanced OpenSSL using OP-TEE Enhanced OpenSSL on i.MX Processors App Note Source Code The purpose of this document is to describe how to add the support of accelerated OP-TEE OS with CAAM on top of OpenSSL.  On The Fly AES Decryption OTFAD App Note OTFAD Tool  OTFAD support in i.MX 7ULP Application Processor Tampering Application  Tampering Application on i.MX 7D SabreSD Board Source Code  The document describes the steps required for software configuration and physical setup for both passive and active tampering on i.MX 7D. Android™ Security User's Guide & User's Guide    Android Security User's Guide     Guide for customization work on security features supported by i.MX Android software. It provides an overview of the i.MX Android security features and it focuses on how to configure and use these security features. Android User's Guide      User Guide provides instructions for: • Downloading, patching, and building the software components that create the Android™ image. • Hardware/software configurations for programming the boot media and Building OTA update packages. i.MX ROMs Log Events i.MX ROMs Log Events This document describes the details of ROM log events for i.MX 6/7/8/9 series ROM.  Device Recovery  HABv4 closed device recovery using UUU Certain i.MX devices require the DCD pointer in IVT to be cleared before singing the recovery image. This document describes this procedure.   Secure Elements Quick start guide for EdgeLock™ SE05x & i.MX 8M Quick start guide for EdgeLock™ SE050 & i.MX 6UltraLite Quick start guide for A71CH & i.MX 6UltraLite Ease ISA/IEC 62443 compliance with EdgeLock SE05x   Interfacing Secure Elements with the i.MX  Binding a host device to EdgeLock SE05x Binding MCUs with TrustZone® and Cryptographic Acceleration and Assurance Module (CAAM) to SE050x Secure Element Known Limitations & Guidelines Known limitations and guidelines document This page contains known limitations in various IPs with i.MX processors. i.MX Security Community  i.MX Security community page This is the parent page for various collateral related to security on i.MX Application Processors Vulnerability Management Vigiles™ Software | NXP Vigiles is a Software Composition Analysis (SCA) tool that helps generate and analyze a Software Bill of Materials (SBOM) for publicly known cybersecurity vulnerabilities, particularly CVEs. Vigiles is optimized for embedded systems, and it provides a complete vulnerability lifecycle management tool.         Training: Best Practices for Triaging Common Vulnerabilities and Exposures (CVEs) in Embedded Systems | NXP Training: Introducing: Vigiles Training: Full Life-Cycle Security Maintenance of Embedded Linux BSPs Training: BSP Security Maintenance - Best Practices for Vulnerability Monitoring and Remediation i.MX Security Applications GitHub - i.MX Security Apps   GitHub for NXP Contains security applications like: - CAAM demo applications - Enhanced OpenSSL using OP-TEE - HSM SHE examples - Demo CAAM Blobs - Manufacturing protection verification tool Security Reference Manuals Link to Various i.MX Security Reference Manuals      Linux BSP Reference Manual Linux BSP and Reference Manuals   Security Certification PSA Level 1 NXP PSA L1 Certified Products PSA Level 2 EdgeLock Secure Enclave  PSA Level 3 i.MX93 EdgeLock Secure Enclave SESIP 1 i.MX 7ULP SESIP 2 EdgeLock Secure Enclave CAVP i.MX 8ULP AES i.MX 8ULP DRBG Please contact your NXP representative on the latest processor security certification status  Security Compliance Ease ISA/IEC 62443-4-2 Compliance with i.MX 8ULP Ease ISA/IEC 62443-4-2 Compliance with i.MX 8XLite Describes how i.MX SoCs can be used to facilitate the implementation of ISA/IEC 62443-4-2 requirements. Security Blogs U.S. Cyber Trust Mark: NXP Is Ready for the Paradigm Shift with EdgeLock® Assurance Program Securing Your Industrial Systems with IEC 62443   IoT Security Just Got Easier: EdgeLock 2GO Programming Partners Simplify Device Provisioning  U.S. Cyber Trust Mark: Security Guidance for IoT Product Developers How NXP Supports Customers to Achieve 62443 Compliance EdgeLock 2GO service gives device OEMs a secure, simple and flexible way to provision and manage device credentials, over the entire lifecycle of the device. Security Whitepapers Security Primitives: Requirements in (I)IoT Systems  SECURING-INDUSTRIAL-IOT  Security Subsystems for System-on-Chip (SoC) Solutions   Functional Safety and Security: Essential and Complementary Disciplines for Modern Systems  The Emergence of Post-Quantum Cryptography  A solution for 360 degree Industrial Internet Security/ABB-MSFT-NXP     

  *Ask local NXP Field Representative members for missing SRMs. They may be available to share under NDA.   i.MX Family Security Reference Manual   i.MX 6 Family i.MX 6ULL/ULZ  i.MX 6UltraLite  i.MX 6SoloLite/SLL i.MX 6SoloX  i.MX 6DQ/6DLS/DQPlus     i.MX 7 Family i.MX 7ULP i.MX 7Dual/Solo   i.MX 8M Family i.MX 8M Quad/QuadLite/Dual i.MX 8M Mini i.MX 8M Nano  i.MX 8M Plus    i.MX 8 Family i.MX 8QuadMax/QuadPlus  i.MX 8QuadXPlus/DualXPlus i.MX 8DualXL/XLite    i.MX 8ULP  i.MX 8ULP *   i.MX 9 Family i.MX 93   *Please check with your NXP Field Representative. Preliminary SRM's may be available to share under NDA.

Overview A vulnerability (CVE-2022-45163) has been identified on select devices when configured in Serial Download Protocol (SDP) mode. In the security-enabled configuration, memory contents could potentially leak via the respective SDP port in cold and warm boot attacks. The recommended mitigation is to completely disable the SDP mode by programming an eFUSE. Impact NXP Device Family Impacted Silicon Revisions i.MX RT101x All i.MX RT102x All i.MX RT105x/6x All i.MX 6 Family All i.MX 7Dual/Solo All i.MX 7ULP All i.MX 8M Quad All i.MX 8M Mini All Vybrid (VFxxx) All   Mitigation  The recommended mitigation is to Disable SDP in production devices by setting the SDP_DISABLE One Time Programmable (OTP)  eFuse to a value of 1’b1.  If available, also set UART Serial Download Disable OTP eFuse bit to 1’b1.   Additional Information For more details, a Security Bulletin is available on the i.MX Security Portal for customers.  NXP has also published an updated Security Checklist including best practices in securing production devices  For access or further information, please contact your NXP Field Support Representative or enter a support request.    Acknowledgment NXP would like to thank the NCC Group for the responsible disclosure of this vulnerability. _________________________________________________________________________ Please note this information is preliminary and subject to change. To the best of NXP's knowledge, the information contained herein is accurate and reliable as of the date of publication; however, NXP does not assume any liability for the accuracy and completeness of the information.

Deny By Default Enforcing enhanced security in the default state of the SoC out of reset, the Resource Domain Controller(RDCs) are deployed in i.MX 8ULP A1 SoC to implement a deny-by-default (DBD) architecture so that all accesses are denied unless specifically configured to allow access. Once the SoC boots up, the Apps cores can request EdgeLock Secure Enclave to release access of RDCs to respective cores for further configuration.   More information on this feature is attached.

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:    

Build steps:   1. Build U-Boot and SPL: a. Get U-Boot source: https://source.codeaurora.org/external/imx/uboot-imx/‍‍‍‍‍‍‍‍‍‍‍‍ Checkout target release branch   b. Build images: # Add secure boot features in the boot image echo CONFIG_AHAB_BOOT=y >> configs/imx8ulp_evk_defconfig make imx8ulp_evk_defconfig make all‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Output images: $(UBOOT_SRC)/u-boot.bin $(UBOOT_SRC)/spl/u-boot-spl.bin‍‍‍‍ 2. ARM Trusted Firmware: a. Obtain the ATF source: https://source.codeaurora.org/external/imx/imx-atf/‍‍‍‍‍‍‍‍‍‍‍‍ Checkout target release branch   b. Build image: make PLAT=imx8ulp bl31‍‍‍‍‍‍‍‍‍‍‍‍ (WITHOUT optee) make PLAT=imx8ulp SPD=opteed bl31 (WITH optee)   Output images: $(ATF_SRC)/build/imx8ulp/release/bl31.bin‍‍‍‍‍‍‍‍‍‍‍‍   3. (Optional) OPTEE: a. Obtain the OPTEE source: https://source.codeaurora.org/external/imx/imx-optee-os/ Checkout target release branch   b. Build image: cd $(OPTEE_SRC) ./scripts/nxp_build.sh imx-mx8ulpevk   Output images: $(OPTEE_SRC)/build.imx-mx8ulpevk/tee-imx-mx8ulpevk.bin   4. Get/Build M33 boot image: a. Obtain the M33 source: Go to http://mcuxpresso.nxp.com Click on Select Development Board Dropdown Boards Dropdown i.MX Select EVK-MIMX8ULP board Click on Build MCUXpresso SDK vX.XX.X (select version available for BSP release) Select appropriate options and click on "DOWNLOAD SDK"   b. Build M33 Hello World demo image: cd SDK_<version>_EVK-MIMX8ULP/boards/evkmimx8ulp/demo_apps/hello_world/armgcc ARMGCC_DIR=<compiler location> ./build_all.sh   Output images: cd $(M33_SRC)/boards/evkmimx8ulp/demo_apps/hello_world/armgcc$ boards/evkmimx8ulp/demo_apps/hello_world/armgcc Target: Flash ./flash_debug/sdk20-app.bin ./flash_release/sdk20-app.bin Target: RAM ./debug/sdk20-app.bin ./release/sdk20-app.bin   b. (or) Get M33 demo image: wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/imx8ulp-m33-demo-2.11.0.bin Find out the latest demo image version from Linux Release Notes in BSP release Make downloaded demo image package executable and accept EULA chmod +x imx8ulp-m33-demo-2.11.0.bin ./imx8ulp-m33-demo-2.11.0.bin Sentinel firmware source located at: $(M33_SRC)/imx8ulp_m33_*.bin Choose the demo image you would like to use   5. Get IMX-MKIMAGE source: https://source.codeaurora.org/external/imx/imx-mkimage/‍‍‍‍‍‍‍‍‍‍‍ Checkout target release branch   6. Get Sentinel FW image: wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.2.bin Find out the latest firmware version from Linux Release Notes in BSP release Make downloaded firmware package executable and accept EULA chmod +x firmware-sentinel-0.2.bin ./firmware-sentinel-0.2.bin Sentinel firmware source located at: $(SENTINEL_FW_SRC/mx8ulpa0-ahab-container.img    7. Get uPower FW image: wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-upower-0.1.1.bin Find out the latest firmware version from Linux Release Notes in BSP release Make downloaded firmware package executable and accept EULA chmod +x firmware-upower-0.1.1.bin ./firmware-upower-0.1.1.bin uPower firmware source located at: $(UPOWER_FW_SRC)/upower.bin   8. Prepare to build i.MX8 ULP boot image: Gather necessary images: The following images are needed to generate boot image. SPL and U-boot images u-boot.bin u-boot-spl.bin ATF image bl31.bin (Optional) OPTEE image tee-imx-mx8ulpevk.bin (Optional) M33 demo image (for Dualboot/LP boot modes) sdk20-app.bin (or) imx8ulp_m33_*.bin Sentinel FW mx8ulpa0-ahab-container.img uPower FW upower.bin Script to copy necessary files: #!/bin/bash cd $(IMXMKIMAGE_SRC) echo "Copying SPL and u-boot images" cp -v $(UBOOT_SRC)/spl/u-boot-spl.bin iMX8ULP/ cp -v $(UBOOT_SRC)/u-boot.bin iMX8ULP/ echo echo "Copying ATF image" cp -v $(ATF_SRC)/build/imx8ulp/release/bl31.bin iMX8ULP/ echo echo "(Optional)Copying OPTEE image" cp -v $(OPTEE_SRC)/build.imx-mx8ulpevk/tee-imx-mx8ulpevk.bin iMX8ULP/tee.bin echo echo "(Optional) M33 demo image (for Dualboot/LP boot modes)" cp -v $(M33_SRC)/sdk20-app.bin iMX8ULP/m33_image.bin #(or) #cp -v $(M33_SRC)/imx8ulp_m33_*.bin iMX8ULP/m33_image.bin echo echo "Copying Sentinel FW" cp -v $(SENTINEL_FW_SRC)/mx8ulpa0-ahab-container.img iMX8ULP/ echo echo "Copying uPower FW" cp -v $(UPOWER_FW_SRC)/upower.bin iMX8ULP/ echo echo "Build instructions" echo "make SOC=iMX8ULP flash_singleboot" echo "make SOC=iMX8ULP flash_singleboot_m33" echo "make SOC=iMX8ULP flash_dualboot" echo "make SOC=iMX8ULP flash_dualboot_m33"   9. (A core) Build singleboot/_m33 or dualboot boot image:   Since the final boot image is made up of multiple containers, the 3rd container needs to be built first and signed. Then the 2nd contianer needs to be built and signed and concatenated with the 2nd container to build the final flash.bin image. Since the 1st container containing the Sentinel FW is already signed, its simply concatenated during the final image build process. For more details look into the "iMX8ULP/soc.mk" file in imx-mkimage repository.   Build u-boot-atf-container.img file: Output from command "make SOC=iMX8ULP u-boot-atf-container": .... 465604 bytes (466 kB, 455 KiB) copied, 0.00443882 s, 105 MB/s AP file_offset = 0xe4800 size = 0x71c00 CST: CONTAINER 0 offset: 0x0 CST: CONTAINER 0: Signature Block: offset is at 0x190 DONE. Note: Please copy image to offset: IVT_OFFSET + IMAGE_OFFSET Sign the u-boot-atf-container.img file: a. Prepare CSF file: imx8ulp-u-boot-atf-container.csf [Header] Target = AHAB Version = 1.0 ...... [Authenticate Data] # Binary to be signed generated by mkimage File = "u-boot-atf-container.img" # Offsets = Container header Signature block (printed out by mkimage) Offsets = 0x000 0x190 b. Sign u-boot-atf-container.img file: ../linux64/bin/cst --o u-boot-atf-container.img.signed --i imx8ulp-u-boot-atf-container.csf #Copy the signed u-boot-atf-container.img.signed image to imx-mkimage to build final image cp -rv u-boot-atf-container.img.signed $(IMXMKIMAGE_SRC)/iMX8ULP/u-boot-atf-container.img Build final flash.bin file: Output from command "make SOC=iMX8ULP flash_singleboot": .... 78100 bytes (78 kB, 76 KiB) copied, 0.000954499 s, 81.8 MB/s AP file_offset = 0xf400 size = 0x13400 CST: CONTAINER 0 offset: 0x400 CST: CONTAINER 0: Signature Block: offset is at 0x510 DONE. Note: Please copy image to offset: IVT_OFFSET + IMAGE_OFFSET append u-boot-atf-container.img at 138 KB 1369+0 records in 1369+0 records out 1401856 bytes (1.4 MB, 1.3 MiB) copied, 0.00915428 s, 153 MB/s Sign the final flash.bin file: a. Prepare CSF file: imx8ulp-flash.csf [Header] Target = AHAB Version = 1.0 ...... [Authenticate Data] # Binary to be signed generated by mkimage File = "flash.bin" # Offsets = Container header Signature block (printed out by mkimage) Offsets = 0x400 0x510 b. Sign final flash.bin image: ../linux64/bin/cst --o signed-flash.bin --i imx8ulp-flash.csf #Final signed flash.bin image is ready "signed-flash.bin"   9. (M core) Build dualboot_m33 boot image:   The boot image built for M core starts from an offset of 0x1000 as the first 0x1000 is reserved for configuration information of the flash. Thus, when applying the CSF details from the build in CSF file, the 0x1000 offset needs to be added. The 1st container contains the Sentinel FW which is already signed by NXP so only 2nd container with M33 boot image needs to be signed. Build final flash.bin file: Output from command "make SOC=iMX8ULP flash_dualboot_m33": .... M4 file_offset = 0xf400 size = 0xcc00 CST: CONTAINER 0 offset: 0x400   <---- Add 0x1000 offset CST: CONTAINER 0: Signature Block: offset is at 0x510 <---- Add 0x1000 offset DONE. Note: Please copy image to offset: IVT_OFFSET + IMAGE_OFFSET ./../scripts/fspi_packer.sh ../scripts/fspi_header_atxp 0+1 records in 0+1 records out 512 bytes copied, 0.000273614 s, 1.9 MB/s 112+0 records in 112+0 records out 114688 bytes (115 kB, 112 KiB) copied, 0.000980111 s, 117 MB/s 3+0 records in 3+0 records out 1536 bytes (1.5 kB, 1.5 KiB) copied, 0.000267603 s, 5.7 MB/s F(Q)SPI IMAGE PACKED Sign the final flash.bin file: a. Prepare CSF file: imx8ulp-flash_m33.csf [Header] Target = AHAB Version = 1.0 ...... [Authenticate Data] # Binary to be signed generated by mkimage File = "flash.bin" # Offsets = Container header Signature block (printed out by mkimage) Offsets = 0x1400 0x1510 b. Sign final flash.bin image: ../linux64/bin/cst --o signed-flash.bin --i imx8ulp-flash_m33.csf #Final signed flash.bin image is ready "signed-flash.bin"    

Secure boot on i.MX 8MPlus (865)     Secure boot on i.MX 8MPlus (865) Introduction: 1. Boot Flow: 2. BootImage layout: Build steps: 1. Build U-Boot and SPL: a. Get U-Boot source: b. Build images: 2. ARM Trusted Firmware: a.Obtain the ATF source: b. Build image: 3. Get the DDR FW images: 4. Get IMX-MKIMAGE source: 5. Build the i.MX8 MP boot image: a. Gather necessary images: b. Build flash.bin c. Print HAB blocks 6.Sign the final image (manual method): a. Prepare CSF files: b. Prepare the signed image:   Introduction: This document can be used as an example to build a signed boot image for i.MX 8MPlus application processor. It is a subset of i.MX8MQ secure boot document as most of the information is similar. This document omits Code Signing Tool and HAB Key Generation information needed for a successful secure boot. The i.MX8MQ secure boot document covers those needed topics. A typical boot image involves an SPL, DDR firmware, ARM-Trusted Firmware (ATF) and U-BOOT images. 1. Boot Flow:     2. Boot Image layout:     Build steps:   1. Build U-Boot and SPL: a. Get U-Boot source:         https://source.codeaurora.org/external/imx/uboot-imx/‍‍‍‍‍‍‍‍‍‍‍‍         b. Build images:         # Add secure boot features in boot image echo CONFIG_IMX_HAB=y >> configs/imx8mp_evk_defconfig make imx8mp_evk_defconfig make all‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍         Output images:         $(UBOOT_SRC)/u-boot.bin $(UBOOT_SRC)/u-boot-nodtb.bin $(UBOOT_SRC)/spl/u-boot-spl.bin $(UBOOT_SRC)/arch/arm/dts/imx8mp-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍‍‍‍         2. ARM Trusted Firmware: a. Obtain the ATF source:         https://source.codeaurora.org/external/imx/imx-atf/‍‍‍‍‍‍‍‍‍‍‍‍         b. Build image:         make PLAT=imx8mp bl31‍‍‍‍‍‍‍‍‍‍‍‍         Output images:         $(ATF_SRC)/build/imx8mp/release/bl31.bin‍‍‍‍‍‍‍‍‍‍‍‍         3. Get the DDR FW image:         Get the latest firmware-imx binary. Check IMX Release Notes. wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin chmod 777 firmware-imx-8.0.bin ./firmware-imx-8.0.bin Accept the LICENSE AGREEMENT cd firmware-imx-8.0         Output images:         $(DDRFW_SRC)/firmware/ddr/synopsys/lpddr4_pmu_train_*‍‍‍‍‍‍‍‍‍         4. Get IMX-MKIMAGE source:         https://source.codeaurora.org/external/imx/imx-mkimage/‍‍‍‍‍‍‍‍‍‍‍         5. Build the i.MX8 MP boot image: a. Gather necessary images: The following images are needed to generate boot image. SPL and U-boot images u-boot.bin u-boot-nodtb.bin u-boot-spl.bin imx8mp-evk.dtb ATF image bl31.bin DDR firmware images lpddr4_pmu_train_1d_dmem.bin lpddr4_pmu_train_1d_imem.bin lpddr4_pmu_train_2d_dmem.bin lpddr4_pmu_train_2d_imem.bin Script to copy necessary files:         #!/bin/bash cd $(IMXMKIMAGE_SRC) echo "Copying SPL and u-boot images" cp -v $(UBOOT_SRC)/spl/u-boot-spl.bin iMX8M/ cp -v $(UBOOT_SRC)/u-boot.bin iMX8M/ cp -v $(UBOOT_SRC)/u-boot-nodtb.bin iMX8M/ cp -v $(UBOOT_SRC)/arch/arm/dts/imx8mp-evk.dtb iMX8M/ echo echo "Copying DDR FW" cp -v $(DDRFW_SRC)/firmware/ddr/synopsys/lpddr4_pmu_train_* iMX8M/ echo echo "Copying ATF image" cp -v $(ATF_SRC)/build/imx8mp/release/bl31.bin iMX8M/ echo "Build instructions" echo "make SOC=iMX8MP flash_evk" echo "Print HAB blocks" echo "make SOC=iMX8MP print_fit_hab"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ echo "Flash SD card" echo "sudo dd if=iMX8M/flash.bin of=/dev/sd<block> bs=1k seek=33 && sync"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ #!/bin/bash cd $(IMXMKIMAGE_SRC) echo "Copying SPL and u-boot images" cp -v $(UBOOT_SRC)/spl/u-boot-spl.bin iMX8M/ cp -v $(UBOOT_SRC)/u-boot.bin iMX8M/ cp -v $(UBOOT_SRC)/u-boot-nodtb.bin iMX8M/ cp -v $(UBOOT_SRC)/arch/arm/dts/imx8mp-evk.dtb iMX8M/ echo echo "Copying DDR FW" cp -v $(DDRFW_SRC)/firmware/ddr/synopsys/lpddr4_pmu_train_* iMX8M/ echo echo "Copying ATF image" cp -v $(ATF_SRC)/build/imx8mp/release/bl31.bin iMX8M/ echo "Build instructions" echo "make SOC=iMX8MP flash_evk" echo "Print HAB blocks" echo "make SOC=iMX8MP print_fit_hab"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ echo "Flash SD card" echo "sudo dd if=iMX8M/flash.bin of=/dev/sd<block> bs=1k seek=33 && sync"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍​         b. Build flash.bin Output from command "make SOC=iMX8MP flash_evk": ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x1a000 dcd_off 0x0 image_off 0x1a040 csf_off 0x44600  <---- Offset required to copy SPL CSF binary to SPL image spl hab block: 0x7e0fd0 0x1a000 0x2e600    <----- Goes into SPL CSF file Second Loader IMAGE: sld_header_off 0x57c00 sld_csf_off 0x58c20 <---- Offset required to copy FIT CSF binary to FIT image ld hab block: 0x401fcdc0 0x57c00 0x1020 <---- Goes into FIT CSF file   c. Print HAB blocks Using the command "make SOC=iMX8MP print_fit_hab": 0x40200000 0x5AC00 0x9AAC8  }  0x910000 0xFCC90 0x9170         }---- Goes into FIT CSF file 0xFE000000 0xFE804 0x4D268  } 0x402A2090 0x105E00 0x688D 6. Sign the final image (manual method): a. Prepare CSF files: imx8mp-spl.csf [Header] Version = 4.3 Hash Algorithm = sha256 ...... [Authenticate Data] Verification index = 2 Blocks = 0x7e0fd0 0x1a000 0x2e600 "flash.bin" imx8mp-fit.csf [Header] Version = 4.3 Hash Algorithm = sha256 ....... [Authenticate Data] Verification index = 2 Blocks = 0x401fcdc0 0x57c00 0x1020 "flash.bin", \ 0x40200000 0x5AC00 0x9AAC8 "flash.bin", \ 0x910000 0xFCC90 0x9170 "flash.bin", \ 0xFE000000 0xFE804 0x4D268 "flash.bin", \ 0x402A2090 0x105E00 0x688D "flash.bin" b. Prepare the signed image: Script to prepare signed flash image: #! /bin/bash echo "generate SPL csf data..." ../linux64/bin/cst --o imx8mp-spl_csf.bin --i imx8mp-spl.csf echo "generate FIT csf data..." ../linux64/bin/cst --o imx8mp-fit_csf.bin --i imx8mp-fit.csf cp flash.bin signed-flash.bin echo "insert SPL csf data to ..." dd if=imx8mp-spl_csf.bin of=signed-flash.bin seek=$((0x44600)) bs=1 conv=notrunc echo "insert FIT csf data to ..." dd if=imx8mp-fit_csf.bin of=signed-flash.bin seek=$((0x58c20)) bs=1 conv=notrunc echo "signed-flash.bin is ready" echo "Flash SD card" echo "sudo dd if=signed-flash.bin of=/dev/sd<block> bs=1k seek=33 && sync"      

Overview A privilege escalation software vulnerability had been discovered in the Arm Trusted Firmware (imx-atf) component of the NXP BSP. Description A privileged local attacker could set or clear the low bit of an arbitrary byte memory in the Trusted Execution Environment (TEE)/TrustZone OS, defeating the isolation of secure memory from the Rich Execution Environment (REE). Exploitation requires the attacker to execute arbitrary code in REE kernel context or u-boot (Non-secure EL1) to issue Secure Monitor Calls (SMCs). https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8m/imx8mp/gpc.c?h=f1d7187f261ebf4b8a2a70d638d4bfc0a9b26c29#n210 The domain id is not bounded in the function "imx_gpc_pm_domain_enable", leading to this potential overflow and privilege escalation.  Impact NXP BSP versions prior to L5.10.52-2.1.0-rc1 i.MX 8 processors using ATF Mitigation This vulnerability has been addressed from NXP BSP versions L5.10.52-2.1.0-rc1 release and beyond. For customers using previous NXP BSP releases, the following commit will need to be backported/applied: ----  commit 32e8f05e5df514ff4c948508d9542cfe2729cb55 Author: Jacky Bai <ping.bai@nxp.com> Date: Tue Jul 13 16:06:29 2021 +0800 LF-4198 plat: imx8m: Fix the potential array overflow Check the domain_id to make sure the index passed by the Rich-OS does not exceed the range of the domain arrays. Signed-off-by: Jacky Bai <ping.bai@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> ----- A patch that addresses this potential security vulnerability has also been attached to this thread.  

[Background] 1.We release the UUU tool instead of MFG tool for the newer BSP release. In this blog, the UUU version is 1.2.39. 2.We clear the DCD address , then sign the u-boot image, then set the DCD address again for the MFG tool before. 3.This method does not work for UUU tool with i.MX6UL. We will get HAB error events when we try to boot signed image which has no issue with MFG tool by UUU tool. => hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 --------- HAB Event 1 ----------------- event data: 0xdb 0x00 0x1c 0x42 0x33 0x18 0xc0 0x00 0xca 0x00 0x14 0x00 0x02 0xc5 0x00 0x00 0x00 0x00 0x0a 0x1c 0x87 0x7f 0xf4 0x00 0x00 0x09 0x6c 0x00 STS = HAB_FAILURE (0x33) RSN = HAB_INV_SIGNATURE (0x18) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 2 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x00 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 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x2c 0x00 0x00 0x01 0xe8 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 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x7f 0xf4 0x20 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 5 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x87 0x80 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB Event 6 ----------------- event data: 0xdb 0x00 0x14 0x42 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x00 0x91 0x00 0x00 0x00 0x00 0x01 0xe8 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) => [Reason]          UUU doesn’t clear the DCD which MFG tool did before for 6UL, so we don’t need to clear the DCD before signing the image by CST tool.    [code signing steps]                    Below is the code signing steps I used, and I have verified it with HAB closed i,MX6UL device. Commands in CST3.1 terminal      1）../linux64/bin/cst -o csf.bin -i uboot_4.14.78_sdp.csf The content of  uboot_4.14.78_sdp.csf can be ---------------------------------------------- [Header]     Version = 4.2     Hash Algorithm = sha256     Engine Configuration = 0     Certificate Format = X509     Signature Format = CMS     Engine = ANY   [Install SRK]     # Index of the key location in the SRK table to be installed     File = "../crts/SRK_1_2_3_4_table.bin"     Source index = 0   [Install CSFK]     # Key used to authenticate the CSF data     File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem"   [Authenticate CSF]   [Install Key]     # Key slot index used to authenticate the key to be installed     Verification index = 0     # Target key slot in HAB key store where key will be installed     Target Index = 2     # Key to install     File= "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem"   [Authenticate Data]     # Key slot index used to authenticate the image data     Verification index = 2     # Authenticate Start Address, Offset, Length and file     Blocks = 0x877ff400 0x00000000 0x00096c00 "u-boot-dtb.imx"   [Authenticate Data]     # Key slot index used to authenticate the image data     Verification index = 2     # Authenticate Start Address, Offset, Length and file     Blocks =  0x00910000 0x0000002c 0x000001e8 "u-boot-dtb.imx" -------------------------------------- 2）cat u-boot-dtb.imx csf.bin > u-boot-signed.bin   Commands in UUU window method 1: SDP command line mode uuu.exe -s   U>SDP: dcd -f u-boot-signed.bin 1:1>Start Cmd:SDP: dcd -f u-boot-signed.bin New USB Device Attached at 1:1 209%1:1>Okay Okay U>SDP: write -f u-boot-signed.bin -ivt 0 1:1>Start Cmd:SDP: write -f u-boot-signed.bin -ivt 0 New USB Device Attached at 1:1 100%1:1>Okay Okay U>SDP: jump -f u-boot-signed.bin 1:1>Start Cmd:SDP: jump -f u-boot-signed.bin New USB Device Attached at 1:1 6400%1:1>Okay Okay  method 2: simple method uuu.exe u-boot-signed.bin Commands in 6UL console U-Boot 2018.03-dirty (Feb 25 2019 - 18:15:01 -0800)   CPU:   Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz) CPU:   Industrial temperature grade (-40C to 105C) at 33C Reset cause: POR Model: Freescale i.MX6 UltraLite 14x14 EVK Board Board: MX6UL 14x14 EVK DRAM:  512 MiB MMC:   FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... Card did not respond to voltage select! *** Warning - No block device, using default environment   Failed (-5) Display: TFT43AB (480x272) Video: 480x272x24 In:    serial Out:   serial Err:   serial Card did not respond to voltage select! flash target is MMC:1 Card did not respond to voltage select! MMC card init failed! Card did not respond to voltage select! ** Block device MMC 1 not supported Net: Warning: ethernet@020b4000 using MAC address from ROM eth1: ethernet@020b4000 [PRIME] Warning: ethernet@02188000 using MAC address from ROM , eth0: ethernet@02188000 Fastboot: Normal Boot from USB for mfgtools Use default environment for                              mfgtools Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else bootz ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot:  0 => hab_status   Secure boot enabled   HAB Configuration: 0xcc, HAB State: 0x99 No HAB Events Found!

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.

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

1. Background 2. Issue description 3. Impacted devices 4. Workarounds 4.1 Do not re-install a key if the key slot is already being used. 4.2 Use only one Authenticate Data command per CSF. 4.3 Prevent Unlock CSF from being added by CST. 4.4 Remove any unnecessary commands from CSF. 4.5 Do not add extensions to key certificates. 5. Conclusion 1. Background The HABv4 in Boot ROM allows users to store up to 5 public keys (1 SRK, 1 CSF Key, 3 IMG Keys) to Key Indexes which can be used to authenticate boot images. The current implementation of hab4_pki_tree.sh script generates a basic PKI tree that contains up to 4 SRKs with a single CSF key and IMG key per SRK. If necessary users can generate additional keys using OpenSSL or add_key.sh script. In the default configuration, HAB installs SRK in slot 0, CSF Key in slot 1, and IMG Keys in slots 2-4. Users can store additional IMG keys in the remaining slots by adding an Install Key command in CSF. - Key Index 0 = SRK Table - Key Index 1 = CSF Key - Key Index 2 = IMG Key - Key Index 3 = IMG Key (Optional) - Key Index 4 = IMG Key (Optional) In HABv4 it is possible to include up to four SRKs in a signed image, although only one SRK can be used per reset cycle. Additional IMG keys must be generated from the same SRK. When HAB processes the Install Key command it verifies the Target Index, copies the key to respective Key Index in OCRAM HAB Persistent Memory Region, and validates the Key against the SRK defined in the Verification index. [Install Key]     Verification index = 0     Target Index = 2     File= "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" Overwriting occupied key slots is not allowed, although a repeated command to reinstall the same public key occupying the target slot will allocate the persistent memory, decode the key and compare it with the key already installed on this slot. 2. Issue description Due to a memory limitation in OCRAM Persistent Memory Region in HAB versions prior to v4.4.0, users storing multiple IMG keys can face an Exhausted Storage Region (HAB_OVR_STORAGE) error in certain i.MX devices which indicate that the system is low in persistent memory. --------- HAB Event 1 ----------------- event data:         0xdb 0x00 0x1c 0x42 0x33 0x2d 0xc0 0x00         0xca 0x00 0x14 0x00 0x04 0xc5 0x1d 0x00         0x00 0x00 0x10 0x10 0x19 0x00 0x00 0x00         0x00 0x00 0xd0 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_OVR_STORAGE (0x2D) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) This issue only happens with 4096-bit or 3072-bit* IMG keys, multiple smaller keys can be stored in OCRAM Persistent Memory Region without errors. In i.MX 8MQ TO 1.0 the available HAB persistent memory can be lower due to the presence of a 2048-bit HDMI firmware key. In this case the issue can happen when trying to re-install the third 3072-bit IMG key. 3. Impacted devices The following devices are impacted by this limitation:  Device Silicon Revision (TO) i.MX 8MQ 1.0 i.MX 8MM 1.0 i.MX 7ULP 2.0 i.MX 7SD 1.1 -> 1.3 i.MX 6DQP 1.0 -> 1.1 i.MX 6DQ 1.2 -> 1.6 i.MX 6DLS 1.1 -> 1.4 i.MX 6SX 1.2 -> 1.4 i.MX 6SL 1.2 -> 1.4 i.MX 6SLL 1.0 -> 1.1 i.MX 6UL 1.1 -> 1.2 i.MX 6ULL 1.0 -> 1.1 i.MX 6ULZ 1.0 i.MX RT1050 1.0 -> 1.1 i.MX RT1020 1.0 Users storing multiples IMG keys can adopt the workarounds mentioned in this document to prevent this issue. The HAB_OVR_STORAGE event can happen when trying to install the third 4096-bit IMG key in the following devices: • i.MX 7ULP 2.0 • i.MX 7SD 1.0 → 1.3 • i.MX 6DQP 1.0 • i.MX 6DQ 1.1 → 1.3 • i.MX 6DLS 1.1 → 1.3 • i.MX 6SX 1.2 → 1.3 • i.MX 6SL 1.2 → 1.4 • i.MX 6SLL 1.0 → 1.1 • i.MX 6UL 1.0 → 1.1 • i.MX 6ULL 1.0 → 1.1 • i.MX RT1050 1.0 → 1.1 • i.MX RT1020 1.0 In certain devices affected by the RNG self-test issue or CAAM manufacturing protection issue the available HAB persistent memory is lower due to the presence of a HAB Warning on this memory region. In this case, this event can happen when trying to install the second 4096-bit IMG Key: • i.MX 8MQ 1.0 • i.MX 8MM 1.0 • i.MX 6DQP 1.1 • i.MX 6DQ 1.6 • i.MX 6SX 1.4 • i.MX 6UL 1.2 • i.MX 6SDL 1.4 In i.MX8MQ TO 1.0 the available HAB persistent memory can be lower due to the presence of a 2048-bit HDMI firmware key. In this case, the issue can occurs when trying to re-install the third 3072-bit IMG key. 4. Workarounds The workaround for this issue is to preserve the HAB persistent memory region. We recommend users to use smaller keys, 3072-bit keys gives a good margin. In case using a signed HDMI firmware in i.MX8MQ TO 1.0 it’s recommended to use 2048-bit keys. In case it’s required to use multiple 4096-bit keys the following methods can be adopted in order to preserve persistent memory region: 4.1 Do not re-install a key if the key slot is already being used. The current CST implementation does not allow the user to sign an image without installing the respective key, the following two commands are mandatory in CSF: [Install Key]     Verification index = 0     Target Index = 2     File= "../crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" [Authenticate Data]     Verification index = 2     Blocks = <image_load_addr> 0x0 0x<image_size> "image1.bin" When authenticating an image the HAB code encounters an Install Key command, it attempts to copy this key to persistent memory before checking if it matches the one already installed in the key slot. In a situation with 4 or more 4096-bit keys that are installed the re-installation of a key may cause an out of memory error. In order to avoid the key re-installation users can use the same CSF file that installed the key for the first time. This can be achieved by following the next method. 4.2 Use only one Authenticate Data command per CSF. When authenticating multiple images or regions with the same key, a single Authenticate Data command can be used, users can use multiple blocks lines as the example below: [Authenticate Data]     Verification index = 4     Blocks = 0x<image_load_addr> 0x0 0x<image_size> "imageX.bin", \                   0x<image_load_addr> 0x0 0x<image_size> "imageX.bin" 4.3 Prevent Unlock CSF from being added by CST. This can be achieved by setting Engine=SW or Engine=ANY in CSF Header. Setting Engine=SW increases the boot time since the image authentication is not hardware accelerated. [Header]     Version = 4.2     Hash Algorithm = sha256     Engine Configuration = 0     Certificate Format = X509     Signature Format = CMS     Engine = ANY Users need to make sure RNG_TRIM fuse is set appropriately otherwise the board may fail to boot in closed mode, for more details please check AN4581. 4.4 Remove any unnecessary commands from CSF. Make sure to have only necessary commands in CSF file. For more details on each command and its purpose please refer to CST user’s guide in CST package. 4.5 Do not add extensions to key certificates. The use of extension in key certificates may require more space in OCRAM persistent memory region, avoiding its use can preserve the persistent region. Customer planning to use this feature should refer to Optional Extended Key Usage x.509 Extension not Supported document. 5. Conclusion Adopting the methods mentioned on this document it’s possible to use one extra key slot. For a full list of the number of 4096-bit IMG keys supported please check the table below. Device Silicon Revision (TO) IMG Keys supported i.MX 8MQ[1] 1.0 2 i.MX 8MM[2] 1.0 2 i.MX 7ULP 2.0 3 i.MX 7SD 1.1 -> 1.3 3 i.MX 6DQP 1.0 3 1.1 2 i.MX 6DQ 1.1 -> 1.3 3 1.6 2 i.MX 6DLS 1.1 -> 1.3 3 1.4 2 i.MX 6SX 1.2 -> 1.3 3 1.4 2 i.MX 6SL 1.2 -> 1.4 3 i.MX 6SLL 1.0 -> 1.1 3 i.MX 6UL 1.0 -> 1.1 3 1.2 2 i.MX 6ULL 1.0 -> 1.1 3 i.MX 6ULZ 1.0 3 i.MX RT1050 1.0 -> 1.1 3 i.MX RT1020 1.0 3 [1]: In case using a signed HDMI firmware in i.MX8 MQ TO 2.0 it’s possible to use 3x 3092-bit IMG keys by adopting the methods mentioned in this document. [2]: In case SoC is not impacted by the CAAM manufacturing protection issue it's possible to use up to 3x 4096-bit keys. In devices supporting HAB v4.4.0 or newer it's possible to store up to 3 4096-bit image keys. This issue does not impact the Secure Boot flow and does not compromise the i.MX security.

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: 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

Background: The Code signing tool has been used to create signed images which contains the certificates and signatures. This information is captured by HAB to authenticate the image in the chip. HAB processes the set of commands from the CSF and authenticates the image serially. The process not only involves authenticating the boot image but also verification of various components like certificates, SRK fuses etc. Verification of all these components and finally authenticating the image is necessary to completely validate a signed image. Introduction: A typical CSF file is as follows: [Header]     Version = 4.1     Hash Algorithm = sha256     Engine Configuration = 0     Certificate Format = X509     Signature Format = CMS [Install SRK]     File = "../crts/SRK_1_2_3_4_table.bin"     Source index = 0 [Install CSFK]     File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate CSF] [Install Key]     Verification index = 0     Target index = 2     File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate Data]     Verification index = 2     Blocks = 0x177FF400  0x000  0x93c00 "u-boot.bin" CST tool interprets and converts this CSF file into a set of commands in binary format. These commands are then processed by HAB to verify each component. [Header] - Header information is used by CST to validate certain necessary configuration needed by HAB to process. [Install SRK] - HAB processes this command as follows (in no particular order): 1. Copy SRK table in persistent memory 2. Compare hash of SRK table (SHA256) with SRK fuses 3. Install the SRK1 key [Install CSFK] - HAB processes this command as follows: 1. Install CSF key 2. Verify CSF certificate against SRK certificate. [Authenticate CSF] 1. Authenticate CSF image using the CSF public key in CSF certificate [Install Key] 1. Install IMG key 2. Verify IMG certificate against SRK certificate. [Authenticate Data] 1. Authenticate boot image using the IMG public key in IMG certificate. The Installation of keys cannot be performed offline but the verification and authentication steps can be performed using OpenSSL. Verification and Authentication: Before starting to authenticate the components of the CSF file, they need to be extracted first. The components that need to be extracted are SRK table, CSF and IMG certificates, CSF and Image signatures. Please use csf_parser tool to extract these components from your signed boot image or CSF binary. csf_parser -d -c u-boot_csf.bin This extracts the files as follows: output/ ├── cert0.der <-- CSF certificate ├── cert1.der <-- IMG certificate ├── debug_log.txt ├── parsed_output.txt ├── sig0.bin <-- CSF signature ├── sig1.bin <-- Boot image signature └── SRKTable.bin Compare SRK table with SRK hash: 1. #Create SRK fuses from SRK table and compare with SRK hash in the chip ./createSRKFuses <SRK table> <Number of SRKs> <SRK key length> 2. #Verify CSF certificate against SRK certificate. (Similarly IMG certificate against SRK certificate) Using openssl command line the procedure to verify the certificate chain is as follows: openssl verify -verbose -CAfile CA1_sha256_2048_65537_v3_ca_crt.pem -untrusted SRK1_sha256_2048_65537_v3_ca_crt.pem CSF1_1_sha256_2048_65537_v3_usr_crt.pem Manually verify signature of certificate with the signer: Note: Pay attention to the color of the text for matching data Signer: SRK1 Certificate : CSF1 1. # Extract encrypted signature from Certificate CSF1 openssl asn1parse -in CSF1_1_sha256_2048_65537_v3_usr_crt.der -inform der   570:d=1  hl=2 l=  13 cons: SEQUENCE             572:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption   583:d=2  hl=2 l=   0 prim: NULL                 585:d=1  hl=4 l= 257 prim: BIT STRING openssl asn1parse -inform DER -in CSF1_1_sha256_2048_65537_v3_usr_crt.der -out enc_sig_csf1.bin -noout -strparse 585 2. #Extract SRK1 public key from SRK1 certificate openssl x509 -in SRK1_sha256_2048_65537_v3_ca_crt.pem -pubkey -noout > SRK1_pubkey.pem 3. # Decrypt the encrypted signature from CSF1 certificate with SRK1 public key openssl rsautl -verify -inkey SRK1_pubkey.pem -in enc_sig_csf1.bin -pubin > sig_csf1.bin 4. # Get the Hash from the CSF1 signature openssl asn1parse -in sig_csf1.bin -inform DER ....     0:d=0  hl=2 l=  49 cons: SEQUENCE               2:d=1  hl=2 l=  13 cons: SEQUENCE               4:d=2  hl=2 l=   9 prim: OBJECT            :sha256    15:d=2  hl=2 l=   0 prim: NULL                  17:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:8E8D56112C3CBDB00806407256BD0E68CDD707AEDFBC2FC3327E5D1B3544EBDF 5. # Get the Hash of CSF1 certificate body openssl asn1parse -in CSF1_1_sha256_2048_65537_v3_usr_crt.der -inform DER -strparse 4 -out CSF1_body.der -noout sha256sum CSF1_body.der 8e8d56112c3cbdb00806407256bd0e68cdd707aedfbc2fc3327e5d1b3544ebdf  CSF1_body.der 6. #Compare the hashes. If hashes match, the CSF1 is verified against SRK1. Authenticating the CSF binary image using Openssl command line: 1. #Parse the CSF signature openssl asn1parse -in sig0.bin -inform der ….   187:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest   198:d=7  hl=2 l=  34 cons: SET                  200:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:09A369AD89EB5DAB81B9034B5E4CF698431318386201A2719FE1784B44AE0DC4   234:d=5  hl=2 l=  13 cons: SEQUENCE             236:d=6  hl=2 l=   9 prim: OBJECT            :rsaEncryption   247:d=6  hl=2 l=   0 prim: NULL                 249:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX DUMP]:389A07D62CEF65442BEA7AD9E64729DAB8255298CF5CCF0524AF16B07D89B128 CE955E9D15BCB3E11D956699A8413BECA9AE26E5ADA1D4EECDA71376F88ECBF3B59F15A8791FA12CECE1A9471C1153FAD3EE99B37708D7 67D62B1FC4DF932644E3FD679E55B650D4FDFBF8CD92710CE88C64480029E827CB9B67320B61B8E7E9C315A9CA5194BF45E42E7CD136AC5 2DAE58EDECBD387E0DA64F90A2B65C5AA6174436758C1E332369A74B9E726924E1E0A60EEDA4EA1F17E8E14785495F5A8207AA0F2E776F6 F810ED4781CB4B6E432B25C0E31F278FB96DCE567D4EC21FC4513DF5158828109FF9A600556146AEFC0F8B7D2EB296EAD2D4772C439117E4 EC31 2. #Compare hash of CSF binary image with hash in message-digest         a. #Determine the length of CSF commands from CSF binary  od -tx1 -N 4 u-boot_csf.bin 0000000 d4 00 50 41         b. #Extract CSF commands (as per CSF file) in binary dd if=u-boot_csf.bin of=csf_commands.bin bs=1 count=80 && sync         c. #Hash the csf_commands output file sha256sum csf_commands.bin 09a369ad89eb5dab81b9034b5e4cf698431318386201a2719fe1784b44ae0dc4  csf_commands.bin         d. #Compare the hash generated of csf_commands with that in the Signature file in #1 3. #Extract encrypted hash from the signature openssl asn1parse -in sig0.bin -inform der -offset 249 -out enc_digest_csf.der -noout dd if=enc_digest_csf.der of=enc_digest_csf.hex bs=1 skip="$(expr `stat --printf="%s" enc_digest_csf.der` - 256)" 4. #Get public CSF1 key from CSF1 certificate openssl x509 -in CSF1_1_sha256_2048_65537_v3_usr_crt.pem -pubkey -noout > CSF1_pubkey.pem 5. #Decrypt the encrypted hash using CSF1 public key openssl rsautl -verify -inkey CSF1_pubkey.pem -in enc_digest_csf.hex -pubin > digest_CSF1_signedAttr.der 6. #Extract CSF1 signed attribute’s digest from DER encoded digest file openssl asn1parse -in digest_CSF1_signedAttr.der -inform der     0:d=0  hl=2 l=  49 cons: SEQUENCE               2:d=1  hl=2 l=  13 cons: SEQUENCE               4:d=2  hl=2 l=   9 prim: OBJECT            :sha256    15:d=2  hl=2 l=   0 prim: NULL                  17:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:132DC3E6E5CF08C20CD16A5888BFAABB9F1D0E3B298D7D6FDEC0F16D8346C89E 7. #Determine the Signed content to calculate the digest openssl cms -in sig0.bin -inform DER -cmsout -noout -print …..         signedAttrs:             object: contentType (1.2.840.113549.1.9.3)             value.set:               OBJECT:pkcs7-data (1.2.840.113549.1.7.1)             object: signingTime (1.2.840.113549.1.9.5)             value.set:               UTCTIME:Sep 13 21:54:45 2018 GMT             object: messageDigest (1.2.840.113549.1.9.4)             value.set:               OCTET STRING:                 0000 - 09 a3 69 ad 89 eb 5d ab-81 b9 03 4b 5e   ..i...]....K^                 000d - 4c f6 98 43 13 18 38 62-01 a2 71 9f e1   L..C..8b..q..                 001a - 78 4b 44 ae 0d c4                        xKD... …… 8.  #Visualizing same content in ASN.1 format to extract it openssl asn1parse -in sig0.bin -inform DER -i …..   127:d=5  hl=2 l= 105 cons:      cont [ 0 ]           129:d=6  hl=2 l=  24 cons:       SEQUENCE             131:d=7  hl=2 l=   9 prim:        OBJECT            :contentType   142:d=7  hl=2 l=  11 cons:        SET                  144:d=8  hl=2 l=   9 prim:         OBJECT            :pkcs7-data   155:d=6  hl=2 l=  28 cons:       SEQUENCE             157:d=7  hl=2 l=   9 prim:        OBJECT            :signingTime   168:d=7  hl=2 l=  15 cons:        SET                  170:d=8  hl=2 l=  13 prim:         UTCTIME           :180913215445Z   185:d=6  hl=2 l=  47 cons:       SEQUENCE             187:d=7  hl=2 l=   9 prim:        OBJECT            :messageDigest   198:d=7  hl=2 l=  34 cons:        SET                  200:d=8  hl=2 l=  32 prim:         OCTET STRING      [HEX DUMP]:09A369AD89EB5DAB81B9034B5E4CF698431318386201A2719FE1784B44AE0DC4 …… 9. #Extract the Signed Attributes using ASN.1 dd if=sig0.bin of=signedAttr_csf_sig.hex bs=1 skip=127 count=107 && sync 10. #Replace the First byte in signedAttr_uboot_sig.hex file 0xA0 with 0x31 as per RFC5652 11. #Determine SHA256 (Hashing algorithm mentioned in signature) sha256sum signedAttr_csf_sig.hex 132dc3e6e5cf08c20cd16a5888bfaabb9f1d0e3b298d7d6fdec0f16d8346c89e  signedAttr_csf_sig.hex 12. #Compare the digest of signed Attributes with the digest determined from encrypted hash in #6 Authenticating the u-boot binary image using Openssl command line: 1. #Parse the Image signature openssl asn1parse -in sig1.bin -inform der ….   187:d=7  hl=2 l=   9 prim: OBJECT            :messageDigest   198:d=7  hl=2 l=  34 cons: SET                  200:d=8  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:44909B596C1FD47A11FF0B2D21E5A1466F3847CEE1494970DFAE815DBD72C463   234:d=5  hl=2 l=  13 cons: SEQUENCE             236:d=6  hl=2 l=   9 prim: OBJECT            :rsaEncryption   247:d=6  hl=2 l=   0 prim: NULL                 249:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX DUMP]:B16F157E7AD984BC42D18236304890AD78E67A230394ECD16E312B 6F6F3BA26A5BB891D3490219586C4D12D76A40B92D2A29346A5F86EFE39955F6958F3CF0CF4786B657E8B9312A7B65E4E3B99 7B4CBDFCB441B7F8BB13DF94593AE61BAA7AE21265FD4756417A7B83DCCC145A6B3B034A37098B74EFEA617B8990804501B0 F8FDB7E28723F53F9E910A67953C57C0B656890C75CDBDD80F85BB4B9AC7C0133A5F8B1D580A392A0D1B262EBA875FBEE523 F880C506941C7035E927931A9BBC0DD05877BADFE06BD4C87982B05463AD00BBA0EBDCEFC53DC9B8F24FB44A3A6C32249215 2DF2DF7098CF7A792BF62678429D42AE438F896A5A5ECE124F9755278 2. #Compare hash of image with hash in message-digest sha256sum u-boot.imx 44909b596c1fd47a11ff0b2d21e5a1466f3847cee1494970dfae815dbd72c463  u-boot.imx 3. #Extract encrypted hash from the signature openssl asn1parse -in sig1.bin -inform der -offset 249 -out enc_digest_uboot.der -noout dd if=enc_digest_uboot.der of=enc_digest_uboot.hex bs=1 skip="$(expr `stat --printf="%s" enc_digest_uboot.der` - 256)" 4. #Get public IMG1 key from IMG1 certificate openssl x509 -in IMG1_1_sha256_2048_65537_v3_usr_crt.pem -pubkey -noout > IMG1_pubkey.pem 5. #Decrypt the encrypted hash using IMG1 public key openssl rsautl -verify -inkey IMG1_pubkey.pem -in enc_digest_uboot.hex -pubin > digest_IMG1_signedAttr.der 6. #Extract IMG1 signed attribute’s digest from DER encoded digest file openssl asn1parse -in digest_IMG1_signedAttr.der -inform der     0:d=0  hl=2 l=  49 cons: SEQUENCE               2:d=1  hl=2 l=  13 cons: SEQUENCE               4:d=2  hl=2 l=   9 prim: OBJECT            :sha256    15:d=2  hl=2 l=   0 prim: NULL                  17:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:17440A2439C79DEC3DB298EFB8F477C9F41E8DE10CBC2620392EEE8EBD3B7F66 7. #Determine  the Signed content to calculate the digest openssl cms -in sig1.bin -inform DER -cmsout -noout -print …..         signedAttrs:             object: contentType (1.2.840.113549.1.9.3)             value.set:               OBJECT:pkcs7-data (1.2.840.113549.1.7.1)             object: signingTime (1.2.840.113549.1.9.5)             value.set:               UTCTIME:Sep 13 21:54:45 2018 GMT             object: messageDigest (1.2.840.113549.1.9.4)             value.set:               OCTET STRING:                 0000 - 44 90 9b 59 6c 1f d4 7a-11 ff 0b 2d 21   D..Yl..z...-!                 000d - e5 a1 46 6f 38 47 ce e1-49 49 70 df ae   ..Fo8G..IIp..                 001a - 81 5d bd 72 c4 63                        .].r.c …… 8. #Visualizing same content in ASN.1 format to extract it openssl asn1parse -in sig1.bin -inform DER -i …..   127:d=5  hl=2 l= 105 cons:      cont [ 0 ]           129:d=6  hl=2 l=  24 cons:       SEQUENCE             131:d=7  hl=2 l=   9 prim:        OBJECT            :contentType   142:d=7  hl=2 l=  11 cons:        SET                  144:d=8  hl=2 l=   9 prim:         OBJECT            :pkcs7-data   155:d=6  hl=2 l=  28 cons:       SEQUENCE             157:d=7  hl=2 l=   9 prim:        OBJECT            :signingTime   168:d=7  hl=2 l=  15 cons:        SET                  170:d=8  hl=2 l=  13 prim:         UTCTIME           :180913215445Z   185:d=6  hl=2 l=  47 cons:       SEQUENCE             187:d=7  hl=2 l=   9 prim:        OBJECT            :messageDigest   198:d=7  hl=2 l=  34 cons:        SET                  200:d=8  hl=2 l=  32 prim:         OCTET STRING      [HEX DUMP]:44909B596C1FD47A11FF0B2D21E5A1466F3847CEE1494970DFAE815DBD72C463 ……. 9. #Extract the Signed Attributes using ASN.1 dd if=sig1.bin of=signedAttr_uboot_sig.hex bs=1 skip=127 count=107 && sync 10. #Replace the First byte in signedAttr_uboot_sig.hex file 0xA0 with 0x31 as per RFC5652 11. #Determine SHA256 (Hashing algorithm mentioned in signature) sha256sum signedAttr_uboot_sig.hex 17440a2439c79dec3db298efb8f477c9f41e8de10cbc2620392eee8ebd3b7f66  signedAttr_uboot_sig.hex 12. #Compare the digest of signed Attributes with the digest determined from the encrypted hash in #6

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

1. Background 2. Issue description 2.1. Conditions to Reproduce 2.2. Execution flow to Reproduce 3. Impacted devices 4. Workarounds 4.1. i.MX 6 4.2. i.MX 7D/S 5. Conclusion 1. Background   The ROM supports the redundant boot for an expansion device. The primary or secondary image is selected, depending on the PERSIST_SECONDARY_BOOT setting. Both images need to be on the same flash (boot source).    In the Security Reference Manual/Reference, Manual redundant boot or secondary boot are the same - meaning the ROM has the capability to select which image to select from the 2 images located on the same flash. NOTE: This functionality should not be confused with Manufacture Boot Support (also a ROM feature) - which refers to the ROM capability to boot an image from 2 different flashes (internal primary boot vs SDMMC MFG boot) before entering USB download mode (SDP)  If the PERSIST_SECONDARY_BOOT is 0, the boot ROM uses address 0x0 for the primary image. If the PERSIST_SECONDARY_BOOT is 1, the boot ROM reads the secondary image table from address 0x200 on the boot media and uses the address specified in the table.   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   For the secondary image support, the primary image must reserve the space for the secondary image table. Refer to figure 1 below for the layout of the typical structure on an expansion device.   Figure 1. Expansion device structures layout   For the Closed mode (Security Configuration Enabled), if there are failures during primary image authentication, the boot ROM turns on the PERSIST_SECONDARY_BOOT bit and performs the software reset. After the software reset, the secondary image is used. Details in Figure 2 below.     Figure 2. Boot flow (click on the image for zoom)   2. Issue description The redundant boot is used only in correlation with HAB and secure boot. As you can see in Figure 2, the switch between the images is done only if the authentication fails. The issue is that the redundant boot support is not triggered when the first image's u-boot code is tampered (not the header). This is because the reset operation after the failed authentication is not properly executed. The reset used by boot ROM to switch between the images is a warm reset - 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. This is not reproduced when the header is altered, because the DCD is not run and the DDR initialization is not finished. So after the warm reset, the DDR initialization will successfully initialize.   2.1. Conditions to Reproduce Secure boot enabled (Chip is closed- Security Configuration Enabled) The real u-boot code of the first image is modified (not the header - IVT, DCD ..etc)    2.2. Execution flow to Reproduce  Prepare the images Compile u-boot with HAB_SUPPORT Sign both images using CST Generate the necessary header for redundant boot using the information from here or just create one link the following. Use the attached write_redundant.sh to write images on the SD card and if needed uncomment the last part to tamper the first image's code/u-boot Flash the images on the SD/eMMC using the attached patches. Make sure you signed the images and closed the chip (aka secure boot is enabled successfully). Modify the first image (only the u-boot code, not the header) Boot the board The primary image is downloaded The DCD is executed and DDR initialization is done successfully Authentication for the first image fails (because the u-boot was altered) The persistent bit is set by boot ROM A warm reset is triggered in order to switch to the secondary image (the warm reset is not correctly resetting/configuring the DDR controller to prepare it for another initialization) The second image is downloaded (because the persistent bit was set) The DCD is executed for the 2nd time and DDR initialization just fails hanging in the SoC/boot ROM   3. Impacted devices All i.MX 6 (All devices and tape-outs) All i.MX 7D/S (All devices and tape-outs) Not Impacted i.MX 7ULP i.MX 8M, 8Mini, 8Nano -  Not impacted as does not use DCD i.MX 8 / 8x devices - Not impacted   4. Workarounds Users should apply the attached patches based on the SoC type directly to u-boot. The patches can be applied to both the first(primary) image and the secondary image, so no need to differentiate.   4.1. i.MX 6 Need to clear the bit17 of CCDR, otherwise, the system will hang up when ROM runs the DCD of the secondary image. The reason is due to the ROM programming 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 runs the DCD of the second image, the system will hang up. In order to address the issue, we simply clear the bit17 of CCDR in DCD and restore it after u-boot boot up.   Please apply to u-boot the attached patch 0001-imx6sll-redundant-boot-fix.patch.   4.2. i.MX 7D/S The DDR controller on the i.MX7D  is different than i.MX6 (NXP MMDC controller). So the fix is different, needing to reset some DDR registers in order to make the DDR work when ROM runs the DCD to do the DDR initialization for the 2nd image.   Please apply to u-boot the attached patch 0001-imx7d-redundant-boot-fix.patch.     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 and does not compromise the i.MX security.

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.