Drop the ENABLE and SUPPORT parts of this, which are redundant.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The ENABLE part of this name is redundant, since all boolean Kconfig
options serve to enable something. The SUPPORT part is also redundant
since Kconfigs can be assumed to enable support for something. Together
they just serve to make these options overly long and inconsistent
with other options.
Rename FIT_ENABLE_SHAxxx_SUPPORT to FIT_SHAxxx
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When we think of Kconfig, we usually think of features that we like
to enable or not. Ideally, we wouldn't use Kconfig to fix a build
issue, although sometimes it might make sense. With Kconfig it's hard
to guarantee that the fix is universal. We can only say that it works
for the set of tested configurations. In the majority of cases, it's
preferable to let the linker figure things out for us.
The reverted commit attempted to fix a build issue by adding an
invisible Kconfig option. This is wrong in several ways:
It invents a new Kconfig variable when CONFIG_HASH already
exists for the same purpose.
Second, hash-checksum.c makes use of the hash_progressive_lookup_algo()
symbol, which is only provided with CONFIG_HASH, but this dependency
was not expressed in the reverted patch.
It feels like Kconfig is turning into a listing of all available
source files, and a buffet to 'select' which ones to compile. The
purpose of this revert is to enable the next change to make use of
CONFIG_HASH instead of adding to Kconfig.
This reverts commit 87316da05f.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Now that we have switched to binman to generate u-boot.itb for all
RISC-V boards, USE_SPL_FIT_GENERATOR is no longer needed and can
be dropped.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It should be FDT, not FTD.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Rick Chen <rick@andestech.com>
Build error occurs when CONFIG_EFI_SECURE_BOOT or
CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled,
because hash-checksum.c is not compiled.
Since hash_calculate() implemented in hash-checksum.c can be
commonly used aside from FIT image signature verification,
this commit itroduces HASH_CALCULATE option to decide
if hash-checksum.c shall be compiled.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The "simple" SPL_LOAD_FIT path is the most compliant with the format
documented in doc/uImage.FIT/source_file_format.txt. The other two
paths to load a FIT are SPL_LOAD_FIT_FULL and the "bootm" command.
Since the Kconfig menu is the most likely place for a new user to see
these options, it seems like the most logical candidate to document
the limitations. This documents the _known_ issues, and is not
intended to be a complete list of all follies.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Vendor Authorized Boot is a security feature for authenticating
the images such as U-Boot, ARM trusted Firmware, Linux kernel,
device tree blob and etc loaded from FIT. After those images are
loaded from FIT, the VAB certificate and signature block appended
at the end of each image are sent to Secure Device Manager (SDM)
for authentication. U-Boot will validate the SHA384 of the image
against the SHA384 hash stored in the VAB certificate before
sending the image to SDM for authentication.
Signed-off-by: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com>
At present these three Kconfigs exist even when bootstage is not enabled.
This is not necessary since bootstage.c is only built if BOOTSTAGE is
enabled.
Make them conditional. Also fix up the overflow message to mention TPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Having the ability to support firmware FIT signatures on the SPL sounds
not so useful if the SPL is not supporting to load a (U-boot) firmware
as a FIT image.
Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Selecting SPL_FIT_SIGNATURE (without selecting U-boot proper
verified boot first) breaks the build due to
CONFIG_FIT_SIGNATURE_MAX_SIZE being undefined, in addition to Kconfig
warnings on RSA and IMAGE_SIGN_INFO unmet dependencies.
Signed-off-by: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Some strange modifications of the FIT can introduce security risks. Add an
option to check it thoroughly, using libfdt's fdt_check_full() function.
Enable this by default if signature verification is enabled.
CVE-2021-27097
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Bruce Monroe <bruce.monroe@intel.com>
Reported-by: Arie Haenel <arie.haenel@intel.com>
Reported-by: Julien Lenoir <julien.lenoir@intel.com>
Config allows to disable printing contents of fitImage to optimize boottime.
Signed-off-by: Ravik Hasija <rahasij@linux.microsoft.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Adds an optional SALT value to AUTOBOOT_STOP_STR_SHA256. If a string
followed by a ":" is prepended to the sha256, the portion to the left
of the colon will be used as a salt and the password will be appended
to the salt before the sha256 is computed and compared.
Signed-off-by: Joel Peshkin <joel.peshkin@broadcom.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Joel Peshkin <joel.peshkin@broadcom.com>
To: u-boot@lists.denx.de
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
In some cases it is necessary to pass parameters to Linux so that it will
boot correctly. For example, the rootdev parameter is often used to
specify the root device. However the root device may change depending on
whence U-Boot loads the kernel. At present it is necessary to build up
the command line by adding device strings to it one by one.
It is often more convenient to provide a template for bootargs, with
U-Boot doing the substitution from other environment variables.
Add a way to substitute strings in the bootargs variable. This allows
things like "rootdev=${rootdev}" to be used in bootargs, with the
${rootdev} substitution providing the UUID of the root device.
For example, to substitute the GUID of the kernel partition:
setenv bootargs "console=/dev/ttyS0 rootdev=${uuid}/PARTNROFF=1
kern_guid=${uuid}"
part uuid mmc 2:2 uuid
bootm
This is particularly useful when the command line from another place. For
example, Chrome OS stores the command line next to the kernel itself. It
depends on the kernel version being used as well as the hardware features,
so it is extremely difficult to devise a U-Boot script that works on all
boards and kernel versions. With this feature, the command line can be
read from disk and used directly, with a few substitutions set up.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present CONFIG_CHROMEOS is used to determine whether verified boot is
in use. The code to implement that is not in U-Boot mainline.
However, it is useful to be able to boot a Chromebook in developer mode
in U-Boot mainline without needing the verified boot code.
To allow this, use CONFIG_CHROMEOS_VBOOT to indicate that verified boot
should be used, and CONFIG_CHROMEOS to indicate that the board supports
Chrome OS. That allows us to define CONFIG_CHROMEOS on coral.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Remove the default value "usb start" for CONFIG_USB_STORAGE as the USB
storage boot initialization is correctly managed by distro boot command
('usb_boot' defined in include/config_distro_bootcmd.h already include
the command 'usb start').
Fixes: 324d77998e ("Define default CONFIG_PREBOOT with right config option")
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This relates to booting since it is the default devicetree provided to
Linux. Move it under the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are a number of miscellaneous boot images at the top level of the
kconfig menu. Move these into the 'boot options' menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the autoboot options are in cmd/Kconfig but they don't really
relate to commands. They relate to booting, so move this menu under the
boot menu.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most of the boot options are in common/Kconfig but that file is already
extremely large. Create a new Kconfig.boot to hold the boot options.
Signed-off-by: Simon Glass <sjg@chromium.org>
