20 Jan, 2020

1 commit


07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

29 Mar, 2017

1 commit

  • For validating images from uboot (Such as Kernel Image), either keys
    from SoC fuses can be used or keys from a verified table of public
    keys can be used. The latter feature is called IE Key Extension
    Feature.

    For Layerscape Chasis 3 based platforms, IE table is validated by
    Bootrom and address of this table is written in scratch registers 13
    and 14 via PBI commands.

    Following are the steps describing usage of this feature:

    1) Verify IE Table in ISBC phase using keys stored in fuses.
    2) Install IE table. (To be used across verification of multiple
    images stored in a static global structure.)
    3) Use keys from IE table, to verify further images.

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Signed-off-by: Udit Agarwal
    Reviewed-by: York Sun

    Udit Agarwal
     

22 Jul, 2016

1 commit

  • As part of Chain of Trust for Secure boot, the SPL U-Boot will validate
    the next level U-boot image. Add a new function spl_validate_uboot to
    perform the validation.

    Enable hardware crypto operations in SPL using SEC block.
    In case of Secure Boot, PAMU is not bypassed. For allowing SEC block
    access to CPC configured as SRAM, configure PAMU.

    Reviewed-by: Ruchika Gupta
    Signed-off-by: Aneesh Bansal
    Signed-off-by: Sumit Garg
    Reviewed-by: Simon Glass
    Reviewed-by: York Sun

    Sumit Garg
     

29 Mar, 2016

3 commits

  • Use a pointer to pass image address to fsl_secboot_validate(),
    instead of using environmental variable "img_addr".

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Reviewed-by: York Sun

    Saksham Jain
     
  • In case of fatal failure during secure boot execution (e.g. header
    not found), reset is asserted to stop execution. If the RESET_REQ
    is not tied to HRESET, this allows the execution to continue.

    Add esbh_halt() after the reset to make sure execution stops.

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Reviewed-by: York Sun

    Saksham Jain
     
  • For secure boot, a header is used to identify key table, signature
    and image address. A new header structure is added for lsch3.

    Currently key extension (IE) feature is not supported. Single key
    feature is not supported. Keys must be in table format. Hence, SRK
    (key table) must be present. Max key number has increase from 4 to
    8. The 8th key is irrevocable. A new barker Code is used.

    Signed-off-by: Aneesh Bansal
    Signed-off-by: Saksham Jain
    Reviewed-by: York Sun

    Saksham Jain
     

28 Jan, 2016

1 commit

  • Chain of Trust is enabled for ARM platforms (LS1021 and LS1043).
    In board_late_init(), fsl_setenv_chain_of_trust() is called which
    will perform the following:
    - If boot mode is non-secure, return (No Change)
    - If boot mode is secure, set the following environmet variables:
    bootdelay = 0 (To disable Boot Prompt)
    bootcmd = CONFIG_CHAIN_BOOT_CMD (Validate and execute Boot script)

    Signed-off-by: Aneesh Bansal
    Acked-by: Ruchika Gupta
    Reviewed-by: York Sun

    Aneesh Bansal
     

26 Jan, 2016

2 commits

  • Some images to be validated are relocated to a dynamic
    address at run time. So, these addresses cannot be known
    befor hand while signing the images and creating the header
    offline.
    So, support is required to pass the image address to the
    validate function as an argument.
    If an address is provided to the function, the address
    field in Header is not read and is treated as a reserved
    field.

    Signed-off-by: Saksham Jain
    Signed-off-by: Aneesh Bansal
    Acked-by: Ruchika Gupta
    Reviewed-by: York Sun

    Aneesh Bansal
     
  • The prototype and defination of function fsl_secboot_validate
    has been changed to support calling this function from another
    function within u-boot.
    Only two aruments needed:
    1) header address - Mandatory
    2) SHA256 string - optional

    Signed-off-by: Saksham Jain
    Signed-off-by: Aneesh Bansal
    Acked-by: Ruchika Gupta
    Reviewed-by: York Sun

    Aneesh Bansal
     

15 Dec, 2015

1 commit


30 Oct, 2015

1 commit

  • For the Chain of Trust, the esbc_validate command supports
    32 bit fields for location of the image. In the header structure
    definition, these were declared as pointers which made them
    64 bit on a 64 bit core.

    Signed-off-by: Aneesh Bansal
    Reviewed-by: York Sun

    Aneesh Bansal
     

06 Mar, 2015

1 commit

  • 1. esbc_validate command is meant for validating header and
    signature of images (Boot Script and ESBC uboot client).
    SHA-256 and RSA operations are performed using SEC block in HW.
    This command works on both PBL based and Non PBL based Freescale
    platforms.
    Command usage:
    esbc_validate img_hdr_addr [pub_key_hash]
    2. ESBC uboot client can be linux. Additionally, rootfs and device
    tree blob can also be signed.
    3. In the event of header or signature failure in validation,
    ITS and ITF bits determine further course of action.
    4. In case of soft failure, appropriate error is dumped on console.
    5. In case of hard failure, SoC is issued RESET REQUEST after
    dumping error on the console.
    6. KEY REVOCATION Feature:
    QorIQ platforms like B4/T4 have support of srk key table and key
    revocation in ISBC code in Silicon.
    The srk key table allows the user to have a key table with multiple
    keys and revoke any key in case of particular key gets compromised.
    In case the ISBC code uses the key revocation and srk key table to
    verify the u-boot code, the subsequent chain of trust should also
    use the same.
    6. ISBC KEY EXTENSION Feature:
    This feature allows large number of keys to be used for esbc validation
    of images. A set of public keys is being signed and validated by ISBC
    which can be further used for esbc validation of images.

    Signed-off-by: Ruchika Gupta
    Signed-off-by: Gaurav Rana
    Reviewed-by: York Sun

    gaurav rana