Changes between Version 17 and Version 18 of venice/secure_boot


Ignore:
Timestamp:
03/25/2024 05:14:42 PM (7 weeks ago)
Author:
Tim Harvey
Comment:

minor changes; move external FIT notes into that section; add general notes about board variations

Legend:

Unmodified
Added
Removed
Modified

  • venice/secure_boot

    v17 v18  
    44== General Notes
    55Secure boot, particularly in the context of our Venice family of Single Board Computers (SBCs), involves several key considerations and procedures. Here are some general notes to keep in mind:
    6  - Signature Node: The process of signing a FIT (Flattened Image Tree) image, as described in our wiki on secure boot, is not overly complex. However, a challenge arises in integrating the signature into the device tree (dt) control for Venice SBCs. Unlike Newport SBCs, where the dtbs are augmented and injected back in, Venice dtbs are contained within the U-Boot ITB (Image Tree Blob) and are built using Binman. As a result, injecting the signature node may require an alternate approach.
    76 - U-Boot Versions: It's crucial to note that this guide was written for U-Boot version v2024.03-venice (or a compatible version), as different U-Boot branches may necessitate distinct configurations.
    87 - SoC specifics: The Gateworks Venice family of Single Board Computers supports IMX8MM, IMX8MN, and IMX8MP SoC's which vary quite a bit and create different binary builds and images for boot firmware. Most of the examples here are for the IMX8MM SoC; if you are using the IMX8MN or IMX8MP it is assumed that you will understand to edit those device-tree files and use those defconfigs for example: arch/arm/dts/imx8m{m,n,p}* configs/imx8m{m,n,p}_venice_defconfig
     8 - Board Versions: Many of the steps here must be customized for your particular board, specifically the device-tree of the board. You will see many instructions here assuming 'imx8mm-venice-gw73xx-0x.dtb' - adjust as necessary.
     9 - SoC Versions: The Venice family supports the IMX8MM, IMX8MN, and IMX8MP SoC's which have different boot firmware, different config files and different flash layouts. Please adjust as neccesary.
    910 - Support for Additional Security Measures: Unlike some other systems that support features like Trusted Platform Module (TPM), OP-TEE (Open Portable Trusted Execution Environment), or CAAM (Cryptographic Acceleration and Assurance Module) keys, Venice SBCs primarily rely on the signature node for secure boot operations.
    1011 - Building boot firmware stand-alone vs modifying the Venice BSP directory: In the examples here we feel it adds clarity to build the 'secure' boot firmware components ouside of the Venice BSP yet we use the toolchain, environment, and some artifacts of the Venice BSP and thus refer to '$VENICE_BSP' as the directory where you have the Venice BSP built on your development host.
    11  - FIT Verification: If a signature node is absent in the controlling device tree blob (dtb), FIT verification will not occur. This behavior is by design, emphasizing the user's responsibility to ensure the presence of a valid signature node. It's advisable to consider patching U-Boot to prevent this if LEGACY mode is not enabled, thus mitigating potential security vulnerabilities.
    12 
    13 
    14 === Chain of Trust
     12
     13== Chain of Trust
    1514The secure boot process on Venice SBCs relies on a robust chain of trust to ensure the integrity and authenticity of the boot process. Here's an overview of the chain of trust and the key steps involved:
    1615 - Power On: The boot process initiates with the IMX BOOT_ROM, which utilizes One-Time Programmable (OTP) fuses to verify the signed Secondary Program Loader (SPL) image loaded into the SRAM/cache. This verification process necessitates the blowing of fuses into OTP and requires the device to be 'locked'.
    … …  
    787786The downside is:
    788787 - it requires another key for the external FIT image vs using the SRK fuse settings and HABv4
     788
     789Important notes for external FIT images:
     790 - Signature Node: The process of signing an external FIT (Flattened Image Tree) image, as described in our wiki on secure boot, is not overly complex. However, a challenge arises in integrating the signature into the device tree (dt) control for Venice SBCs. Unlike Newport SBCs, where the dtbs are augmented and injected back in, Venice dtbs are contained within the U-Boot ITB (Image Tree Blob) and are built using Binman. As a result, injecting the signature node may require an alternate approach.
     791 - FIT Verification: If a signature node is absent in the controlling device tree blob (dtb), FIT verification will not occur. This behavior is by design, emphasizing the user's responsibility to ensure the presence of a valid signature node. It's advisable to consider patching U-Boot to prevent this if LEGACY mode is not enabled, thus mitigating potential security vulnerabilities.
    789792
    790793==== FIT image background information
    … …  
    872875                fdt {
    873876                        description = "fdt";
    874                         data = /incbin/("blobs/imx8mm-venice-gw72xx-0x.dtb");
     877                        data = /incbin/("blobs/imx8mm-venice-gw73xx-0x.dtb");
    875878                        type = "flat_dt";
    876879                        arch = "arm64";
    … …  
    11621165
    11631166                                        uboot-blob {
    1164                                                 filename = "blobs/imx8mm-venice-gw72xx-0x.dtb";
     1167                                                filename = "blobs/imx8mm-venice-gw73xx-0x.dtb";
    11651168                                                type = "blob-ext";
    11661169                                        };