[U-Boot] [PATCH v3 3/7] SECURE_BOOT: split the secure boot functionality in two parts

york sun york.sun at nxp.com
Wed Jan 27 18:01:13 CET 2016


On 01/22/2016 03:10 AM, Aneesh Bansal wrote:
> 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 at nxp.com>
> ---
> Changes in v3:
> None
> 
> Changes in v2:
> CONFIG_ENV_IS_NOWHERE is defined for Secure Boot
> 
>  arch/arm/include/asm/fsl_secure_boot.h     |  16 ++--
>  arch/powerpc/include/asm/fsl_secure_boot.h |  41 +++++-----
>  include/config_fsl_chain_trust.h           | 101 +++++++++++++++++++++++++
>  include/config_fsl_secboot.h               | 116 -----------------------------
>  4 files changed, 135 insertions(+), 139 deletions(-)
>  create mode 100644 include/config_fsl_chain_trust.h
>  delete mode 100644 include/config_fsl_secboot.h
> 

Change subject prefix to "secure_boot:". Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York



More information about the U-Boot mailing list