i.MX Security

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

i.MX Security

Labels

Discussions

Sort by:
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     
View full article
  *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.
View full article
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    
View full article
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.
View full article
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.
View full article
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.
View full article
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.
View full article
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:    
View full article
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"    
View full article
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"      
View full article
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.  
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
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.
View full article
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.
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 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
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
: 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
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