2018-05-07 05:58:06 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2015-03-10 16:38:50 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright 2015 Freescale Semiconductor, Inc.
|
|
|
|
|
*/
|
|
|
|
|
|
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 19:07:24 +08:00
|
|
|
#ifndef __CONFIG_FSL_CHAIN_TRUST_H
|
|
|
|
|
#define __CONFIG_FSL_CHAIN_TRUST_H
|
2015-03-10 16:38:50 +08:00
|
|
|
|
2020-05-11 01:40:09 +08:00
|
|
|
#include <linux/stringify.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 19:07:24 +08:00
|
|
|
#ifdef CONFIG_CHAIN_OF_TRUST
|
|
|
|
|
|
2015-03-10 16:38:50 +08:00
|
|
|
#ifndef CONFIG_EXTRA_ENV
|
|
|
|
|
#define CONFIG_EXTRA_ENV ""
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Control should not reach back to uboot after validation of images
|
|
|
|
|
* for secure boot flow and therefore bootscript should have
|
|
|
|
|
* the bootm command. If control reaches back to uboot anyhow
|
|
|
|
|
* after validating images, core should just spin.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Define the key hash for boot script here if public/private key pair used to
|
|
|
|
|
* sign bootscript are different from the SRK hash put in the fuse
|
|
|
|
|
* Example of defining KEY_HASH is
|
|
|
|
|
* #define CONFIG_BOOTSCRIPT_KEY_HASH \
|
|
|
|
|
* "41066b564c6ffcef40ccbc1e0a5d0d519604000c785d97bbefd25e4d288d1c8b"
|
|
|
|
|
*/
|
|
|
|
|
|
2017-08-15 01:22:17 +08:00
|
|
|
#ifdef CONFIG_USE_BOOTARGS
|
2016-03-23 18:54:43 +08:00
|
|
|
#define CONFIG_SET_BOOTARGS "setenv bootargs \'" CONFIG_BOOTARGS" \';"
|
|
|
|
|
#else
|
|
|
|
|
#define CONFIG_SET_BOOTARGS "setenv bootargs \'root=/dev/ram " \
|
|
|
|
|
"rw console=ttyS0,115200 ramdisk_size=600000\';"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
2015-03-10 16:38:50 +08:00
|
|
|
#ifdef CONFIG_BOOTSCRIPT_KEY_HASH
|
|
|
|
|
#define CONFIG_SECBOOT \
|
|
|
|
|
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
|
2016-03-23 18:54:43 +08:00
|
|
|
CONFIG_SET_BOOTARGS \
|
2015-03-10 16:38:50 +08:00
|
|
|
CONFIG_EXTRA_ENV \
|
|
|
|
|
"esbc_validate $bs_hdraddr " \
|
|
|
|
|
__stringify(CONFIG_BOOTSCRIPT_KEY_HASH)";" \
|
|
|
|
|
"source $img_addr;" \
|
|
|
|
|
"esbc_halt\0"
|
|
|
|
|
#else
|
|
|
|
|
#define CONFIG_SECBOOT \
|
|
|
|
|
"setenv bs_hdraddr " __stringify(CONFIG_BOOTSCRIPT_HDR_ADDR)";" \
|
2016-03-23 18:54:43 +08:00
|
|
|
CONFIG_SET_BOOTARGS \
|
2015-03-10 16:38:50 +08:00
|
|
|
CONFIG_EXTRA_ENV \
|
|
|
|
|
"esbc_validate $bs_hdraddr;" \
|
|
|
|
|
"source $img_addr;" \
|
|
|
|
|
"esbc_halt\0"
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-06-16 13:06:43 +08:00
|
|
|
#ifdef CONFIG_BOOTSCRIPT_COPY_RAM
|
|
|
|
|
#define CONFIG_BS_COPY_ENV \
|
|
|
|
|
"setenv bs_hdr_ram " __stringify(CONFIG_BS_HDR_ADDR_RAM)";" \
|
2016-06-15 01:52:39 +08:00
|
|
|
"setenv bs_hdr_device " __stringify(CONFIG_BS_HDR_ADDR_DEVICE)";" \
|
2015-06-16 13:06:43 +08:00
|
|
|
"setenv bs_hdr_size " __stringify(CONFIG_BS_HDR_SIZE)";" \
|
|
|
|
|
"setenv bs_ram " __stringify(CONFIG_BS_ADDR_RAM)";" \
|
2016-06-15 01:52:39 +08:00
|
|
|
"setenv bs_device " __stringify(CONFIG_BS_ADDR_DEVICE)";" \
|
2015-06-16 13:06:43 +08:00
|
|
|
"setenv bs_size " __stringify(CONFIG_BS_SIZE)";"
|
|
|
|
|
|
2016-03-23 18:54:37 +08:00
|
|
|
/* For secure boot flow, default environment used will be used */
|
2017-04-17 20:37:18 +08:00
|
|
|
#if defined(CONFIG_SYS_RAMBOOT) || defined(CONFIG_NAND_BOOT) || \
|
|
|
|
|
defined(CONFIG_SD_BOOT)
|
|
|
|
|
#if defined(CONFIG_RAMBOOT_NAND) || defined(CONFIG_NAND_BOOT)
|
2015-06-16 13:06:43 +08:00
|
|
|
#define CONFIG_BS_COPY_CMD \
|
2016-06-15 01:52:39 +08:00
|
|
|
"nand read $bs_hdr_ram $bs_hdr_device $bs_hdr_size ;" \
|
|
|
|
|
"nand read $bs_ram $bs_device $bs_size ;"
|
|
|
|
|
#elif defined(CONFIG_SD_BOOT)
|
|
|
|
|
#define CONFIG_BS_COPY_CMD \
|
|
|
|
|
"mmc read $bs_hdr_ram $bs_hdr_device $bs_hdr_size ;" \
|
|
|
|
|
"mmc read $bs_ram $bs_device $bs_size ;"
|
2017-04-17 20:37:18 +08:00
|
|
|
#endif
|
|
|
|
|
#else
|
2016-03-23 18:54:37 +08:00
|
|
|
#define CONFIG_BS_COPY_CMD \
|
2016-06-15 01:52:39 +08:00
|
|
|
"cp.b $bs_hdr_device $bs_hdr_ram $bs_hdr_size ;" \
|
|
|
|
|
"cp.b $bs_device $bs_ram $bs_size ;"
|
2015-03-10 16:38:50 +08:00
|
|
|
#endif
|
2016-03-23 18:54:37 +08:00
|
|
|
#endif /* CONFIG_BOOTSCRIPT_COPY_RAM */
|
2015-03-10 16:38:50 +08:00
|
|
|
|
2015-06-16 13:06:43 +08:00
|
|
|
#ifndef CONFIG_BS_COPY_ENV
|
|
|
|
|
#define CONFIG_BS_COPY_ENV
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef CONFIG_BS_COPY_CMD
|
|
|
|
|
#define CONFIG_BS_COPY_CMD
|
|
|
|
|
#endif
|
|
|
|
|
|
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 19:07:24 +08:00
|
|
|
#define CONFIG_CHAIN_BOOT_CMD CONFIG_BS_COPY_ENV \
|
2015-06-16 13:06:43 +08:00
|
|
|
CONFIG_BS_COPY_CMD \
|
|
|
|
|
CONFIG_SECBOOT
|
2015-03-10 16:38:50 +08:00
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
