1. 27 Jan, 2016 1 commit
    • Aneesh Bansal's avatar
      secure_boot: split the secure boot functionality in two parts · bdc22074
      Aneesh Bansal authored
      There are two phases in Secure Boot
      1. ISBC: In BootROM, validate the BootLoader (U-Boot).
      2. ESBC: In U-Boot, continuing the Chain of Trust by
               validating and booting LINUX.
      
      For ESBC phase, there is no difference in SoC's based on ARM or
      PowerPC cores.
      
      But the exit conditions after ISBC phase i.e. entry conditions for
      U-Boot are different for ARM and PowerPC.
      PowerPC:
      
      If Secure Boot is executed, a separate U-Boot target is required
      which must be compiled with a diffrent Text Base as compared to
      Non-Secure Boot. There are some LAW and TLB settings which are
      required specifically for Secure Boot scenario.
      
      ARM:
      ARM based SoC's have a fixed memory map and exit conditions from
      BootROM are same irrespective of boot mode (Secure or Non-Secure).
      
      Thus the current Secure Boot functionlity has been split into
      two parts:
      CONFIG_CHAIN_OF_TRUST
      This will have the following functionality as part of U-Boot:
      1. Enable commands like esbc_validate, esbc_halt
      2. Change the environment settings based on bootmode, determined
         at run time:
           - If bootmode is non-secure, no change
           - If bootmode is secure, set the following:
               - bootdelay = 0 (Don't give boot prompt)
               - bootcmd = Validate and execute the bootscript.
      
      CONFIG_SECURE_BOOT
      This is defined only for creating a different compile time target
      for secure boot.
      
      Traditionally, both these functionalities were defined under
      CONFIG_SECURE_BOOT. This patch is aimed at removing the requirement
      for a separate Secure Boot target for ARM based SoC's.
      CONFIG_CHAIN_OF_TRUST will be defined and boot mode will be
      determine at run time.
      
      Another Security Requirement for running CHAIN_OF_TRUST is that
      U-Boot environemnt must not be picked from flash/external memory.
      This cannot be done based on bootmode at run time in current U-Boot
      architecture. Once this dependency is resolved, no separate
      SECURE_BOOT target will be required for ARM based SoC's.
      
      Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is
      defining CONFIG_ENV_IS_NOWHERE
      Signed-off-by: default avatarAneesh Bansal <aneesh.bansal@nxp.com>
      Acked-by: default avatarRuchika Gupta <ruchika.gupta@nxp.com>
      Reviewed-by: default avatarYork Sun <york.sun@nxp.com>
      bdc22074
  2. 31 Jul, 2015 1 commit
  3. 21 Apr, 2015 1 commit
    • gaurav rana's avatar
      Add bootscript support to esbc_validate. · 98cb0efd
      gaurav rana authored
      1. Default environment will be used for secure boot flow
       which can't be edited or saved.
      2. Command for secure boot is predefined in the default
       environment which will run on autoboot (and autoboot is
       the only option allowed in case of secure boot) and it
       looks like this:
       #define CONFIG_SECBOOT \
       "setenv bs_hdraddr 0xe8e00000;"                 \
       "esbc_validate $bs_hdraddr;"                    \
       "source $img_addr;"                             \
       "esbc_halt;"
       #endif
      3. Boot Script can contain esbc_validate commands and bootm command.
       Uboot source command used in default secure boot command will
       run the bootscript.
      4. Command esbc_halt added to ensure either bootm executes
       after validation of images or core should just spin.
      Signed-off-by: default avatarRuchika Gupta <ruchika.gupta@freescale.com>
      Signed-off-by: default avatarGaurav Rana <gaurav.rana@freescale.com>
      Reviewed-by: default avatarYork Sun <yorksun@freescale.com>
      98cb0efd