u-boot/arch/arm/include/asm/fsl_secure_boot.h

/* SPDX-License-Identifier: GPL-2.0+ */
/*
 * Copyright 2015 Freescale Semiconductor, Inc.
 * Copyright 2017 NXP
 */

#ifndef __FSL_SECURE_BOOT_H
#define __FSL_SECURE_BOOT_H

#ifdef CONFIG_CHAIN_OF_TRUST
#ifndef CONFIG_SPL_BUILD

#endif /* #ifndef CONFIG_SPL_BUILD */
#endif /* #ifdef CONFIG_CHAIN_OF_TRUST */
#endif
SPDX: Convert all of our single license tags to Linux Kernel style 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 <trini@konsulko.com> 2018-05-06 21:58:06 +00:00			`/* SPDX-License-Identifier: GPL-2.0+ */`
Add bootscript support to esbc_validate. 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: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com> 2015-03-10 08:38:50 +00:00			`/*`
			`* Copyright 2015 Freescale Semiconductor, Inc.`
SECURE_BOOT: Unify memory map for Layerscape based platforms Unify memory map for Layerscape based platforms. This patch includes changes in bootscript, bootscript header and PPA header addresses change as per unified memory map. Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Tested-by: Vinitha Pillai <vinitha.pillai@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com> 2017-08-16 11:13:28 +00:00			`* Copyright 2017 NXP`
Add bootscript support to esbc_validate. 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: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com> 2015-03-10 08:38:50 +00:00			`*/`

			`#ifndef __FSL_SECURE_BOOT_H`
			`#define __FSL_SECURE_BOOT_H`

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> 2016-01-22 11:07:24 +00:00			`#ifdef CONFIG_CHAIN_OF_TRUST`
SECURE_BOOT: Enable chain of trust in SPL framework Override jump_to_image_no_args function to include validation of u-boot image using spl_validate_uboot before jumping to u-boot image. Also define macros in SPL framework to enable crypto operations. Reviewed-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: York Sun <york.sun@nxp.com> 2016-06-14 17:52:38 +00:00			`#ifndef CONFIG_SPL_BUILD`
ls1043ardb: PPA: add PPA validation in case of secure boot As part of Secure Boot Chain of trust, PPA image must be validated before the image is started. The code for the same has been added. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com> 2016-09-01 16:56:44 +00:00
SECURE_BOOT: Enable chain of trust in SPL framework Override jump_to_image_no_args function to include validation of u-boot image using spl_validate_uboot before jumping to u-boot image. Also define macros in SPL framework to enable crypto operations. Reviewed-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Sumit Garg <sumit.garg@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: York Sun <york.sun@nxp.com> 2016-06-14 17:52:38 +00:00			`#endif /* #ifndef CONFIG_SPL_BUILD */`
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> 2016-01-22 11:07:24 +00:00			`#endif /* #ifdef CONFIG_CHAIN_OF_TRUST */`
Add bootscript support to esbc_validate. 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: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Gaurav Rana <gaurav.rana@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com> 2015-03-10 08:38:50 +00:00			`#endif`