summaryrefslogtreecommitdiff
path: root/board
diff options
context:
space:
mode:
authorAneesh Bansal <aneesh.bansal@nxp.com>2016-01-22 16:37:24 +0530
committerYork Sun <york.sun@nxp.com>2016-01-27 08:12:32 -0800
commitbdc22074c511def222f93d1a9d94ec95c462c062 (patch)
tree22d578480e69a56be6b11f58efdee505c4522c80 /board
parent74eecd820f251c6700c828d662a600c01651217f (diff)
downloadu-boot-imx-bdc22074c511def222f93d1a9d94ec95c462c062.zip
u-boot-imx-bdc22074c511def222f93d1a9d94ec95c462c062.tar.gz
u-boot-imx-bdc22074c511def222f93d1a9d94ec95c462c062.tar.bz2
secure_boot: split the secure boot functionality in two parts
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: Aneesh Bansal <aneesh.bansal@nxp.com> Acked-by: Ruchika Gupta <ruchika.gupta@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
Diffstat (limited to 'board')
0 files changed, 0 insertions, 0 deletions