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
|
|
|
|
|
|
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
|
2015-07-31 08:40:03 +00:00
|
|
|
#define CONFIG_CMD_ESBC_VALIDATE
|
|
|
|
|
#define CONFIG_FSL_SEC_MON
|
2016-03-23 10:54:35 +00:00
|
|
|
#define CONFIG_SHA_HW_ACCEL
|
2015-07-31 08:40:03 +00:00
|
|
|
#define CONFIG_SHA_PROG_HW_ACCEL
|
|
|
|
|
|
2016-06-14 17:52:38 +00:00
|
|
|
#define CONFIG_SPL_BOARD_INIT
|
2016-09-13 05:18:23 +00:00
|
|
|
#ifdef CONFIG_SPL_BUILD
|
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 */
|
|
|
|
|
|
2017-04-17 12:37:17 +00:00
|
|
|
#define CONFIG_KEY_REVOCATION
|
|
|
|
|
|
2016-06-14 17:52:38 +00:00
|
|
|
#ifndef CONFIG_SPL_BUILD
|
|
|
|
|
#define CONFIG_CMD_BLOB
|
|
|
|
|
#define CONFIG_CMD_HASH
|
2015-07-31 08:40:03 +00:00
|
|
|
#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).
|
2017-02-09 16:06:11 +00:00
|
|
|
* For LS, this feature is available for all device if IE Table
|
|
|
|
|
* is copied to XIP memory
|
|
|
|
|
* Also, for LS, ISBC doesn't verify this table.
|
2015-07-31 08:40:03 +00:00
|
|
|
*/
|
|
|
|
|
#define CONFIG_FSL_ISBC_KEY_EXT
|
|
|
|
|
|
2016-03-23 10:54:34 +00:00
|
|
|
#endif
|
|
|
|
|
|
2017-03-23 08:18:16 +00:00
|
|
|
#if defined(CONFIG_FSL_LAYERSCAPE)
|
|
|
|
|
/*
|
|
|
|
|
* For fsl layerscape based platforms, ESBC image Address in Header
|
|
|
|
|
* is 64 bit.
|
2016-03-23 10:54:35 +00:00
|
|
|
*/
|
2016-01-22 11:07:22 +00:00
|
|
|
#define CONFIG_ESBC_ADDR_64BIT
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-03-27 18:41:01 +00:00
|
|
|
#ifdef CONFIG_ARCH_LS2080A
|
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
|
2015-03-10 08:38:50 +00:00
|
|
|
#define CONFIG_EXTRA_ENV \
|
2016-06-14 17:52:39 +00:00
|
|
|
"setenv fdt_high 0xffffffff;" \
|
|
|
|
|
"setenv initrd_high 0xffffffff;" \
|
2015-03-10 08:38:50 +00:00
|
|
|
"setenv hwconfig \'fsl_ddr:ctlr_intlv=null,bank_intlv=null\';"
|
2016-03-23 10:54:38 +00:00
|
|
|
#endif
|
2015-03-10 08:38:50 +00:00
|
|
|
|
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)*/
|
2017-01-06 10:28:56 +00:00
|
|
|
#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_FSL_LSCH3) || \
|
2017-04-17 12:37:18 +00:00
|
|
|
defined(CONFIG_SD_BOOT) || defined(CONFIG_NAND_BOOT)
|
2016-03-23 10:54:37 +00:00
|
|
|
#define CONFIG_BOOTSCRIPT_COPY_RAM
|
|
|
|
|
#endif
|
2016-06-14 17:52:39 +00:00
|
|
|
/* The address needs to be modified according to NOR, NAND, SD and
|
|
|
|
|
* DDR memory map
|
|
|
|
|
*/
|
2017-01-06 10:28:56 +00:00
|
|
|
#ifdef CONFIG_FSL_LSCH3
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x580d00000
|
|
|
|
|
#define CONFIG_BS_ADDR_DEVICE 0x580e00000
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_RAM 0xa0d00000
|
|
|
|
|
#define CONFIG_BS_ADDR_RAM 0xa0e00000
|
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.
|
|
|
|
|
*/
|
2017-03-27 18:41:02 +00:00
|
|
|
#if defined(CONFIG_ARCH_LS1043A) || defined(CONFIG_ARCH_LS1046A)
|
2017-04-17 12:37:17 +00:00
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x00000920
|
|
|
|
|
#else
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x00000900
|
|
|
|
|
#endif
|
2017-02-01 12:58:53 +00:00
|
|
|
#define CONFIG_BS_ADDR_DEVICE 0x00000940
|
2016-06-14 17:52:39 +00:00
|
|
|
#define CONFIG_BS_HDR_SIZE 0x00000010
|
|
|
|
|
#define CONFIG_BS_SIZE 0x00000008
|
2017-04-17 12:37:18 +00:00
|
|
|
#elif defined(CONFIG_NAND_BOOT)
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x00800000
|
|
|
|
|
#define CONFIG_BS_ADDR_DEVICE 0x00802000
|
|
|
|
|
#define CONFIG_BS_HDR_SIZE 0x00002000
|
|
|
|
|
#define CONFIG_BS_SIZE 0x00001000
|
2017-03-23 08:18:16 +00:00
|
|
|
#elif defined(CONFIG_QSPI_BOOT)
|
|
|
|
|
#ifdef CONFIG_ARCH_LS1046A
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x40780000
|
|
|
|
|
#define CONFIG_BS_ADDR_DEVICE 0x40800000
|
2017-03-23 08:18:19 +00:00
|
|
|
#elif defined(CONFIG_ARCH_LS1012A)
|
|
|
|
|
#define CONFIG_BS_HDR_ADDR_DEVICE 0x400c0000
|
|
|
|
|
#define CONFIG_BS_ADDR_DEVICE 0x40060000
|
2016-03-23 10:54:37 +00:00
|
|
|
#else
|
2017-03-23 08:18:16 +00:00
|
|
|
#error "Platform not supported"
|
|
|
|
|
#endif
|
|
|
|
|
#define CONFIG_BS_HDR_SIZE 0x00002000
|
|
|
|
|
#define CONFIG_BS_SIZE 0x00001000
|
|
|
|
|
#else /* Default NOR Boot */
|
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
|
2017-03-23 08:18:16 +00:00
|
|
|
#endif
|
2016-06-14 17:52:39 +00:00
|
|
|
#define CONFIG_BS_HDR_ADDR_RAM 0x81000000
|
|
|
|
|
#define CONFIG_BS_ADDR_RAM 0x81020000
|
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
|
2016-03-23 10:54:36 +00:00
|
|
|
#else
|
2016-06-14 17:52:39 +00:00
|
|
|
#define CONFIG_BOOTSCRIPT_HDR_ADDR CONFIG_BS_HDR_ADDR_DEVICE
|
|
|
|
|
/* BOOTSCRIPT_ADDR is not required */
|
2016-03-23 10:54:36 +00:00
|
|
|
#endif
|
2015-03-10 08:38:50 +00:00
|
|
|
|
2016-09-01 16:56:44 +00:00
|
|
|
#ifdef CONFIG_FSL_LS_PPA
|
|
|
|
|
/* 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
|
2017-03-23 08:18:14 +00:00
|
|
|
* #define PPA_KEY_HASH \
|
2016-09-01 16:56:44 +00:00
|
|
|
* "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
|
|
|
|
|
*/
|
2017-03-23 08:18:14 +00:00
|
|
|
#define PPA_KEY_HASH NULL
|
2016-09-01 16:56:44 +00:00
|
|
|
#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>
|
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 */
|
2015-03-10 08:38:50 +00:00
|
|
|
#endif
|
