Commit graph

14 commits

Author SHA1 Message Date
Tom Rini
f4cd75e96a powerpc: Clean up CHAIN_OF_TRUST related options
As things stand currently, there is only one PowerPC platform that
enables the options for CHAIN_OF_TRUST.  From the board header files,
remove a number of never-set options.  Remove board specific values from
arch/powerpc/include/asm/fsl_secure_boot.h as well.  Rework
include/config_fsl_chain_trust.h to not abuse the CONFIG namespace for
constructing CHAIN_BOOT_CMD.  Migrate all of the configurable addresses
to Kconfig.

If any platforms are re-introduced with secure boot support, everything
required should still be here, but now in Kconfig, or requires migration
of an option to Kconfig.

Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-07-05 17:04:15 -04:00
Tom Rini
52aaa1840d nxp: config_fsl_chain_trust.h: Clean up and remove unused portions
The way that secure boot is implemented today on NXP ARM platforms does
not reuse the elements found in include/config_fsl_chain_trust.h to
construct CONFIG_SECBOOT but instead board header files have their
environment setup as needed and then fsl_setenv_chain_of_trust() will
set secureboot in the environment.  Remove a large number of unused
defines here.

Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-07-05 17:04:01 -04:00
Simon Glass
1af3c7f422 common: Drop linux/stringify.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 21:19:23 -04:00
Tom Rini
83d290c56f 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-07 09:34:12 -04:00
Sam Protsenko
5abc1a4523 common: Move CONFIG_BOOTARGS to Kconfig
Also introduce CONFIG_USE_BOOTARGS option so we can control if
CONFIG_BOOTARGS defined at all.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
[trini: Resync r8a779[56]_ulcb, various ls10xx targets]
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-08-14 17:06:06 -04:00
Simon Glass
91c868fe7c Convert CONFIG_ENV_IS_IN_SPI_FLASH to Kconfig
This converts the following to Kconfig:
   CONFIG_ENV_IS_IN_SPI_FLASH

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-07-25 21:31:03 -04:00
Simon Glass
f0bc2b542b Convert CONFIG_ENV_IS_IN_EEPROM to Kconfig
This converts the following to Kconfig:
   CONFIG_ENV_IS_IN_EEPROM

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-07-25 21:22:56 -04:00
Simon Glass
85fc970d74 Convert CONFIG_ENV_IS_IN_FLASH to Kconfig
This converts the following to Kconfig:
   CONFIG_ENV_IS_IN_FLASH

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-07-25 21:20:02 -04:00
Simon Glass
2be296538e Convert CONFIG_ENV_IS_IN_MMC/NAND/UBI and NOWHERE to Kconfig
This converts the following to Kconfig:
   CONFIG_ENV_IS_IN_MMC
   CONFIG_ENV_IS_IN_NAND
   CONFIG_ENV_IS_IN_UBI
   CONFIG_ENV_IS_NOWHERE

In fact this already exists for sunxi as a 'choice' config. However not
all the choices are available in Kconfig yet so we cannot use that. It
would lead to more than one option being set.

In addition, one purpose of this series is to allow the environment to be
stored in more than one place. So the existing choice is converted to a
normal config allowing each option to be set independently.

There are not many opportunities for Kconfig updates to reduce the size of
this patch. This was tested with

   ./tools/moveconfig.py -i CONFIG_ENV_IS_IN_MMC

And then manual updates.  This is because for CHAIN_OF_TRUST boards they
can only have ENV_IS_NOWHERE set, so we enforce that via Kconfig logic
now.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-07-25 21:08:01 -04:00
Ruchika Gupta
762f92a60e arm: ls1043ardb: Add NAND secure boot target
Add NAND secure boot target for ls1043ardb.

- Change the u-boot size defined by a macro for copying the main
  U-Boot by SPL to also include the u-boot Secure Boot header size as
  header is appended to u-boot image. So header will also be copied
  from SD to DDR.
- MACRO for CONFIG_BOOTSCRIPT_COPY_RAM is enabled to copy Bootscript
  from NAND to DDR. Offsets for Bootscript on NAND and DDR have been
  also defined.

Signed-off-by: Vinitha Pillai <vinitha.pillai@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
2017-04-17 09:03:30 -07:00
Sumit Garg
69d4b48c84 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-07-26 09:01:43 -07:00
Saksham Jain
2bfe489085 SECURE_BOOT: Use default bootargs
For secure boot, currently we were using fixed bootargs for all SoCs.
This is not needed and we can use the bootargs which are used in
non-secure 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-29 08:46:23 -07:00
Saksham Jain
3f701cc50a 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-29 08:46:21 -07:00
Aneesh Bansal
bdc22074c5 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-27 08:12:32 -08:00
Renamed from include/config_fsl_secboot.h (Browse further)