Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-11 23:47:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/include/asm/fsl_secure_boot.h

146 lines
4.1 KiB
C
Raw Normal View History

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.
*
* SPDX-License-Identifier: GPL-2.0+
*/
#ifndef __FSL_SECURE_BOOT_H
#define __FSL_SECURE_BOOT_H
#ifdef CONFIG_SECURE_BOOT
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
#ifndef CONFIG_FIT_SIGNATURE
#define CONFIG_CHAIN_OF_TRUST
#endif
#endif
#ifdef CONFIG_CHAIN_OF_TRUST
SECURE_BOOT: Disable IE Key feature for RAMBOOT ISBC Key Extension feature is not applicable for RAMBOOT as there is no way to retrieve the CSF Header and validated IE Key table from SRAM once CPC has been disabled. The feature is only applicable in case of NOR SECURE BOOT. Code Cleanup: The SECURE_BOOT specific defines have been moved from arch-ls102xa/config.h to arm/include/asm/fsl_secure_boot.h Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-07-31 08:40:03 +00:00
#define CONFIG_CMD_ESBC_VALIDATE
#define CONFIG_FSL_SEC_MON
armv8: ls2080rdb: ls2080qds: Add secure boot support Sec_init has been called at the beginning to initialize SEC Block (CAAM) which is used by secure boot validation later for both ls2080a qds and rdb. 64-bit address in ESBC Header has been enabled. Secure boot defconfigs are created for boards (NOR boot). Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:35 +00:00
#define CONFIG_SHA_HW_ACCEL
SECURE_BOOT: Disable IE Key feature for RAMBOOT ISBC Key Extension feature is not applicable for RAMBOOT as there is no way to retrieve the CSF Header and validated IE Key table from SRAM once CPC has been disabled. The feature is only applicable in case of NOR SECURE BOOT. Code Cleanup: The SECURE_BOOT specific defines have been moved from arch-ls102xa/config.h to arm/include/asm/fsl_secure_boot.h Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-07-31 08:40:03 +00:00
#define CONFIG_SHA_PROG_HW_ACCEL
#define CONFIG_RSA_FREESCALE_EXP
armv8/ls1043ardb: add SECURE BOOT target for NOR LS1043ARDB Secure Boot Target from NOR has been added. - Configs defined to enable esbc_validate. - ESBC Address in header is made 64 bit. - SMMU is re-configured in Bypass mode. Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-12-08 08:24:29 +00:00
SECURE_BOOT: Disable IE Key feature for RAMBOOT ISBC Key Extension feature is not applicable for RAMBOOT as there is no way to retrieve the CSF Header and validated IE Key table from SRAM once CPC has been disabled. The feature is only applicable in case of NOR SECURE BOOT. Code Cleanup: The SECURE_BOOT specific defines have been moved from arch-ls102xa/config.h to arm/include/asm/fsl_secure_boot.h Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-07-31 08:40:03 +00:00
#ifndef CONFIG_FSL_CAAM
#define CONFIG_FSL_CAAM
#endif
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
#define CONFIG_SPL_BOARD_INIT
arm: fsl: Adjust ordering of #ifndef CONFIG_SPL_BUILD The secure boot header files incorrectly define SPL options only if CONFIG_SPL_BUILD is defined. This means that the options are only enabled in an SPL build, and not with a normal 'make xxx_defconfig'. This means that moveconfig.py cannot work, since it sees the options as disabled even when they may be manually enabled in an SPL build. Fix this by changing the order. Signed-off-by: Simon Glass <sjg@chromium.org>
2016-09-13 05:18:23 +00:00
#ifdef CONFIG_SPL_BUILD
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
/*
* Define the key hash for U-Boot here if public/private key pair used to
* sign U-boot are different from the SRK hash put in the fuse
* Example of defining KEY_HASH is
* #define CONFIG_SPL_UBOOT_KEY_HASH \
* "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
* else leave it defined as NULL
*/
#define CONFIG_SPL_UBOOT_KEY_HASH NULL
#endif /* ifdef CONFIG_SPL_BUILD */
#ifndef CONFIG_SPL_BUILD
#define CONFIG_CMD_BLOB
#define CONFIG_CMD_HASH
SECURE_BOOT: Disable IE Key feature for RAMBOOT ISBC Key Extension feature is not applicable for RAMBOOT as there is no way to retrieve the CSF Header and validated IE Key table from SRAM once CPC has been disabled. The feature is only applicable in case of NOR SECURE BOOT. Code Cleanup: The SECURE_BOOT specific defines have been moved from arch-ls102xa/config.h to arm/include/asm/fsl_secure_boot.h Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-07-31 08:40:03 +00:00
#define CONFIG_KEY_REVOCATION
#ifndef CONFIG_SYS_RAMBOOT
/* The key used for verification of next level images
* is picked up from an Extension Table which has
* been verified by the ISBC (Internal Secure boot Code)
* in boot ROM of the SoC.
* The feature is only applicable in case of NOR boot and is
* not applicable in case of RAMBOOT (NAND, SD, SPI).
*/
armv8: fsl-lsch3: Add new header for secure boot 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 <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:34 +00:00
#ifndef CONFIG_ESBC_HDR_LS
/* Current Key EXT feature not available in LS ESBC Header */
SECURE_BOOT: Disable IE Key feature for RAMBOOT ISBC Key Extension feature is not applicable for RAMBOOT as there is no way to retrieve the CSF Header and validated IE Key table from SRAM once CPC has been disabled. The feature is only applicable in case of NOR SECURE BOOT. Code Cleanup: The SECURE_BOOT specific defines have been moved from arch-ls102xa/config.h to arm/include/asm/fsl_secure_boot.h Signed-off-by: Aneesh Bansal <aneesh.bansal@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
2015-07-31 08:40:03 +00:00
#define CONFIG_FSL_ISBC_KEY_EXT
#endif
armv8: fsl-lsch3: Add new header for secure boot 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 <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:34 +00:00
#endif
armv8: LS2080A: Consolidate LS2080A and LS2085A LS2080A is the primary SoC, and LS2085A is a personality with AIOP and DPAA DDR. The RDB and QDS boards support both personality. By detecting the SVR at runtime, a single image per board can support both SoCs. It gives users flexibility to swtich SoC without the need to reprogram the board. Signed-off-by: York Sun <york.sun@nxp.com> CC: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2016-04-04 18:41:26 +00:00
#if defined(CONFIG_LS1043A) || defined(CONFIG_LS2080A)
armv8: ls2080rdb: ls2080qds: Add secure boot support Sec_init has been called at the beginning to initialize SEC Block (CAAM) which is used by secure boot validation later for both ls2080a qds and rdb. 64-bit address in ESBC Header has been enabled. Secure boot defconfigs are created for boards (NOR boot). Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:35 +00:00
/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit
armv8: LS2080A: Consolidate LS2080A and LS2085A LS2080A is the primary SoC, and LS2085A is a personality with AIOP and DPAA DDR. The RDB and QDS boards support both personality. By detecting the SVR at runtime, a single image per board can support both SoCs. It gives users flexibility to swtich SoC without the need to reprogram the board. Signed-off-by: York Sun <york.sun@nxp.com> CC: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2016-04-04 18:41:26 +00:00
* Similiarly for LS2080
armv8: ls2080rdb: ls2080qds: Add secure boot support Sec_init has been called at the beginning to initialize SEC Block (CAAM) which is used by secure boot validation later for both ls2080a qds and rdb. 64-bit address in ESBC Header has been enabled. Secure boot defconfigs are created for boards (NOR boot). Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:35 +00:00
*/
secure_boot: include/configs: make secure boot header file uniform The file fsl_secure_boot.h must be included in config file for Secure Boot. This is not required to be protected by any macro. CONFIG_FSL_CAAM must be defined and CONFIG_CMD_HASH should be turned on. The above was missing in some config files and all files have been made uniform in this respect. 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:22 +00:00
#define CONFIG_ESBC_ADDR_64BIT
#endif
armv8: LS2080A: Consolidate LS2080A and LS2085A LS2080A is the primary SoC, and LS2085A is a personality with AIOP and DPAA DDR. The RDB and QDS boards support both personality. By detecting the SVR at runtime, a single image per board can support both SoCs. It gives users flexibility to swtich SoC without the need to reprogram the board. Signed-off-by: York Sun <york.sun@nxp.com> CC: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2016-04-04 18:41:26 +00:00
#ifdef CONFIG_LS2080A
armv8: ls2080: Change env variable "fdt_high" "fdt_high" env variable was set to 0xcfffffff for secure boot. Change it to 0xa0000000 for LS2080 to be consistent with non-secure boot targets. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:38 +00:00
#define CONFIG_EXTRA_ENV \
"setenv fdt_high 0xa0000000;" \
"setenv initrd_high 0xcfffffff;" \
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
#else
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
#define CONFIG_EXTRA_ENV \
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
"setenv fdt_high 0xffffffff;" \
"setenv initrd_high 0xffffffff;" \
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
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
armv8: ls2080: Change env variable "fdt_high" "fdt_high" env variable was set to 0xcfffffff for secure boot. Change it to 0xa0000000 for LS2080 to be consistent with non-secure boot targets. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:38 +00:00
#endif
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
armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR To unify steps for secure boot for xip (eg. NOR) and non-xip memories (eg. NAND, SD), bootscipts and its header are copied to main memory. Validation and execution are performed from there. For other ARM Platforms (ls1043 and ls1020), to avoid disruption of existing users, this copy step is not used for NOR boot. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:37 +00:00
/* Copying Bootscript and Header to DDR from NOR for LS2 and for rest, from
* Non-XIP Memory (Nand/SD)*/
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_LS2080A) || \
defined(CONFIG_SD_BOOT)
armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR To unify steps for secure boot for xip (eg. NOR) and non-xip memories (eg. NAND, SD), bootscipts and its header are copied to main memory. Validation and execution are performed from there. For other ARM Platforms (ls1043 and ls1020), to avoid disruption of existing users, this copy step is not used for NOR boot. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:37 +00:00
#define CONFIG_BOOTSCRIPT_COPY_RAM
#endif
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
/* The address needs to be modified according to NOR, NAND, SD and
* DDR memory map
*/
armv8: LS2080A: Consolidate LS2080A and LS2085A LS2080A is the primary SoC, and LS2085A is a personality with AIOP and DPAA DDR. The RDB and QDS boards support both personality. By detecting the SVR at runtime, a single image per board can support both SoCs. It gives users flexibility to swtich SoC without the need to reprogram the board. Signed-off-by: York Sun <york.sun@nxp.com> CC: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2016-04-04 18:41:26 +00:00
#ifdef CONFIG_LS2080A
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
#define CONFIG_BS_HDR_ADDR_DEVICE 0x583920000
#define CONFIG_BS_ADDR_DEVICE 0x583900000
armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR To unify steps for secure boot for xip (eg. NOR) and non-xip memories (eg. NAND, SD), bootscipts and its header are copied to main memory. Validation and execution are performed from there. For other ARM Platforms (ls1043 and ls1020), to avoid disruption of existing users, this copy step is not used for NOR boot. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:37 +00:00
#define CONFIG_BS_HDR_ADDR_RAM 0xa3920000
#define CONFIG_BS_ADDR_RAM 0xa3900000
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
#define CONFIG_BS_HDR_SIZE 0x00002000
#define CONFIG_BS_SIZE 0x00001000
#else
#ifdef CONFIG_SD_BOOT
/* For SD boot address and size are assigned in terms of sector
* offset and no. of sectors respectively.
*/
#define CONFIG_BS_HDR_ADDR_DEVICE 0x00000800
#define CONFIG_BS_ADDR_DEVICE 0x00000840
#define CONFIG_BS_HDR_SIZE 0x00000010
#define CONFIG_BS_SIZE 0x00000008
armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR To unify steps for secure boot for xip (eg. NOR) and non-xip memories (eg. NAND, SD), bootscipts and its header are copied to main memory. Validation and execution are performed from there. For other ARM Platforms (ls1043 and ls1020), to avoid disruption of existing users, this copy step is not used for NOR boot. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:37 +00:00
#else
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
#define CONFIG_BS_HDR_ADDR_DEVICE 0x600a0000
#define CONFIG_BS_ADDR_DEVICE 0x60060000
#define CONFIG_BS_HDR_SIZE 0x00002000
#define CONFIG_BS_SIZE 0x00001000
#endif /* #ifdef CONFIG_SD_BOOT */
#define CONFIG_BS_HDR_ADDR_RAM 0x81000000
#define CONFIG_BS_ADDR_RAM 0x81020000
armv8: fsl-lsch3: Copy Bootscript and header from NOR to DDR To unify steps for secure boot for xip (eg. NOR) and non-xip memories (eg. NAND, SD), bootscipts and its header are copied to main memory. Validation and execution are performed from there. For other ARM Platforms (ls1043 and ls1020), to avoid disruption of existing users, this copy step is not used for NOR boot. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:37 +00:00
#endif
#ifdef CONFIG_BOOTSCRIPT_COPY_RAM
#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_RAM
#define CONFIG_BOOTSCRIPT_ADDR CONFIG_BS_ADDR_RAM
armv8: ls2080: Add bootscript header addr for secure boot During secure boot, Linux image along with other images are validated using bootscript. This bootscript also needs to be validated before it executes. This requires a header for bootscript. When secure boot is enabled, default bootcmd is changed to first validate bootscript using the header and then execute the script. For ls2080, NOR memory map is different from other ARM SoCs. So a new address on NOR is used for this bootscript header (0x583920000). The Bootscript address is mentioned in this header along with addresses of other images. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:36 +00:00
#else
SECURE_BOOT: Enable SD as a source for bootscript Add support for reading bootscript and bootscript header from SD. Also renamed macros *_FLASH to *_DEVICE to represent SD alongwith NAND and NOR flash. 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:39 +00:00
#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_DEVICE
/* BOOTSCRIPT_ADDR is not required */
armv8: ls2080: Add bootscript header addr for secure boot During secure boot, Linux image along with other images are validated using bootscript. This bootscript also needs to be validated before it executes. This requires a header for bootscript. When secure boot is enabled, default bootcmd is changed to first validate bootscript using the header and then execute the script. For ls2080, NOR memory map is different from other ARM SoCs. So a new address on NOR is used for this bootscript header (0x583920000). The Bootscript address is mentioned in this header along with addresses of other images. Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com> Signed-off-by: Saksham Jain <saksham.jain@nxp.com> Reviewed-by: York Sun <york.sun@nxp.com>
2016-03-23 10:54:36 +00:00
#endif
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
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
#ifdef CONFIG_FSL_LS_PPA
#ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP
#ifdef CONFIG_LS1043A
#define CONFIG_SYS_LS_PPA_ESBC_ADDR 0x600c0000
#endif
#else
#error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
#endif /* ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP */
/* Define the key hash here if SRK used for signing PPA image is
* different from SRK hash put in SFP used for U-Boot.
* Example
* #define CONFIG_PPA_KEY_HASH \
* "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
*/
#define CONFIG_PPA_KEY_HASH NULL
#endif /* ifdef CONFIG_FSL_LS_PPA */
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
#include <config_fsl_chain_trust.h>
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
Reference in a new issue Copy permalink