As discussed previously [1,2], the source command is not safe to use with
verified boot unless there is a key with required = "images" (which has its
own problems). This is because if such a key is absent, signatures are
verified but not required. It is assumed that configuration nodes will
provide the signature. Because the source command does not use
configurations to determine the image to source, effectively no
verification takes place.
To address this, allow specifying configuration nodes. We use the same
syntax as the bootm command (helpfully provided for us by fit_parse_conf).
By default, we first try the default config and then the default image. To
force using a config, # must be present in the command (e.g. `source
$loadaddr#my-conf`). For convenience, the config may be omitted, just like
the address may be (e.g. `source \#`). This also works for images
(`source :` behaves exactly like `source` currently does).
[1] https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9eeded@prevas.dk/
[2] https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005fdd@gmail.com/
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fallback for this function so it can be used without regard to
whether FIT_SIGNATURE is enabled or not.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If the user select the image type "flat_dt" a FIT image will be build.
This breaks the legacy use case of putting a Flat Device Tree into a
legacy u-boot image.
Add a new image type "fdt_legacy" to build a legacy u-boot image
with a "flat_dt" type.
Link: https://lore.kernel.org/all/20221028155205.ojw6tcso2fofgnhm@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
gcc 12 seems to warn on strncpy() as a matter of course. Rewrite the code
a different way to do the same thing, to avoid the warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for filtering out FIT images by phase. Rather than adding yet
another argument to this already overloaded function, use a composite
value, where the phase is only added in if needed.
The FIT config is still selected (and verified) as normal, but the images
are selected based on the phase.
Tests for this come in a little later, as part of the updated VPL test.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to be able to mark an image as related to a phase, so we can
easily load all the images for SPL or for U-Boot proper.
Add this to the FIT specification, along with some access functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Putting these definitions in a header will allow signatures to be
validated independently of bootm.
Signed-off-by: Steven Lawrance <steven.lawrance@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.
Signed-off-by: Simon Glass <sjg@chromium.org>
Remove all but a few that are difficult, relying on legacy CONFIG options
or optional global_data fields.
Drop the duplicate function name in the comment for boot_get_cmdline().
Signed-off-by: Simon Glass <sjg@chromium.org>
Several different firmware users have repetitive code to extract the
firmware data from a FIT. Add some helper functions to reduce the amount
of repetition. fit_conf_get_prop_node (eventually) calls
fdt_check_node_offset_, so we can avoid an explicit if. In general, this
version avoids printing on error because the callers are typically
library functions, and because the FIT code generally has (debug)
prints of its own. One difference in these helpers is that they use
fit_image_get_data_and_size instead of fit_image_get_data, as the former
handles external data correctly.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to update
const-correctness in targeted functions to comply with
coding-rules and avoid const-cast
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
A big part is the DM pinctrl driver, which allows us to get rid of quite
some custom pinmux code and make the whole port much more robust. Many
thanks to Samuel for that nice contribution! There are some more or less
cosmetic warnings about missing clocks right now, I will send the trivial
fixes for that later.
Another big chunk is the mkimage upgrade, which adds RISC-V and TOC0
(secure images) support. Both features are unused at the moment, but I
have an always-secure board that will use that once the DT lands in the
kernel.
On top of those big things we have some smaller fixes, improving the
I2C DM support, fixing some H6/H616 early clock setup and improving the
eMMC boot partition support.
The gitlab CI completed successfully, including the build test for all
161 sunxi boards. I also boot tested on a A64, A20, H3, H6, and F1C100
board. USB, SD card, eMMC, and Ethernet all work there (where applicable).
Most Allwinner sunxi SoCs have separate boot ROMs in non-secure and
secure mode. The "non-secure" or "normal" boot ROM (NBROM) uses the
existing sunxi_egon image type. The secure boot ROM (SBROM) uses a
completely different image type, known as TOC0.
A TOC0 image is composed of a header and two or more items. One item
is the firmware binary. The others form a chain linking the firmware
signature to the root-of-trust public key (ROTPK), which has its hash
burned in the SoC's eFuses. Signatures are made using RSA-2048 + SHA256.
The pseudo-ASN.1 structure is manually assembled; this is done to work
around bugs/quirks in the boot ROM, which vary between SoCs. This TOC0
implementation has been verified to work with the A50, A64, H5, H6,
and H616 SBROMs, and it may work with other SoCs.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This commit enhances mkimage to update the node
/image/pre-load/sig with the public key.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Add a stage pre-load to the command bootm.
Right now, this stage may be used to read a
header and check the signature of the full
image.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Add a stage pre-load that could
check or modify an image.
For the moment, only a header with a signature is
supported. This header has the following format:
- magic : 4 bytes
- version : 4 bytes
- header size : 4 bytes
- image size : 4 bytes
- offset image signature : 4 bytes
- flags : 4 bytes
- reserved0 : 4 bytes
- reserved1 : 4 bytes
- sha256 of the image signature : 32 bytes
- signature of the first 64 bytes : n bytes
- image signature : n bytes
- padding : up to header size
The stage uses a node /image/pre-load/sig to
get some informations:
- algo-name (mandatory) : name of the algo used to sign
- padding-name : name of padding used to sign
- signature-size : size of the signature (in the header)
- mandatory : set to yes if this sig is mandatory
- public-key (madatory) : value of the public key
Before running the image, the stage pre-load checks
the signature provided in the header.
This is an initial support, later we could add the
support of:
- ciphering
- uncompressing
- ...
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
At present mkimage displays the node information but it is not clear what
signing action was taken. Add a message that shows it. For now it only
supports showing a single signing action, since that is the common case.
Sample:
Signature written to 'sha1-basic/test.fit',
node '/configurations/conf-1/signature'
Public key written to 'sha1-basic/sandbox-u-boot.dtb',
node '/signature/key-dev'
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we rely on the key blob being in the global_data fdt_blob
pointer. This is true in U-Boot but not with tools. For clarity, pass the
parameter around.
Signed-off-by: Simon Glass <sjg@chromium.org>
This permits to prepare FIT image description that do not hard-code the
final choice of the signature algorithm, possibly requiring the user to
patch the sources.
When -o <algo> is specified, this information is used in favor of the
'algo' property in the signature node. Furthermore, that property is set
accordingly when writing the image.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
The data blob apparently does not need to be modified through the fit
field of the image_sign_info struct so make it point to const to avoid
the need to cast away constness in functions that assign a pointer to
const data to the field.
fit_image_setup_verify already had to cast away constness as it assigned
a const void * argument to the field. The cast can now be removed.
Signed-off-by: Hannu Lounento <hannu.lounento@vaisala.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This file has a lot of conditional code and much of it is unnecessary.
Clean this up to reduce the number of build combinations.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is only used in one place and does not need to use the
preprocessor. Move it to the C file and convert it to a normal function.
Drop fit_unsupported() since it is not used.
Signed-off-by: Simon Glass <sjg@chromium.org>
We can use the new host_build() function for this, so drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is not needed with Kconfig, since we can use IS_ENABLED() easily
enough. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is not needed with Kconfig, since we can use IS_ENABLED() easily
enough. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is not needed with Kconfig, since we can use IS_ENABLED() easily
enough and the board code is now in a separate file. Update the only place
where this is used and drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add a host Kconfig for FIT_RSASSA_PSS. With this we can use
CONFIG_IS_ENABLED(FIT_RSASSA_PSS) directly in the host build, so drop the
forcing of this in the image.h header.
Drop the #ifdef around padding_pss_verify() too since it is not needed.
Use the compiler to check the config where possible, instead of the
preprocessor.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add a host Kconfig for FIT_VERBOSE. With this we can use
CONFIG_IS_ENABLED(FIT_VERBOSE) directly in the tools build, so drop the
forcing of this in the image.h header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Add a host Kconfig for OF_LIBFDT. With this we can use
CONFIG_IS_ENABLED(OF_LIBFDT) directly in the tools build, so drop the
unnecessary indirection.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Make use of the host Kconfig for FIT. With this we can use
CONFIG_IS_ENABLED(FIT) directly in the host build, so drop the unnecessary
indirection.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
At present when building host tools, we force CONFIG_SHAxxx to be enabled
regardless of the board Kconfig setting. This is done in the image.h
header file.
For SPL we currently just assume the algorithm is desired if U-Boot proper
enables it.
Clean this up by adding new Kconfig options to enable hashing on the host,
relying on CONFIG_IS_ENABLED() to deal with the different builds.
Add new SPL Kconfigs for hardware-accelerated hashing, to maintain the
current settings.
This allows us to drop the image.h code and the I_WANT_MD5 hack.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We are not guaranteed to have the padding_pkcs_15_verify symbol since
commit 92c960bc1d ("lib: rsa: Remove #ifdefs from rsa.h"), and
commit 61416fe9df ("Kconfig: FIT_SIGNATURE should not select RSA_VERIFY")
The padding_algos only make sense with RSA verification, which can now
be disabled in lieu of ECDSA. In fact this will lead to build failures
because of the missing symbol mentioned earlier.
To resolve this, move the padding_algos to a linker list, with
declarations moved to rsa_verify.c. This is consistent with commit
6909edb4ce ("image: rsa: Move verification algorithm to a linker list")
One could argue that the added #ifdef USE_HOSTCC is ugly, and should
be hidden within the U_BOOT_PADDING_ALGO() macro. However, this would
be inconsistent with the "cryptos" list. This logic for was not
previously explored:
Without knowledge of the U_BOOT_PADDING_ALGO() macro, its use is
similar to something being declared. However, should #ifndef
USE_HOSTCC be part of the macro, it would not be obvious that it
behaves differently on host code and target code. Having the #ifndef
outside the macro makes this obvious.
Also, the #ifdef is not always necessary. For example ecda-verify
makes use of U_BOOT_CRYPTO_ALGO() without any accompanying #ifdefs.
The fundamental issue is a lack of separation of host and target code
in rsa_verify. Therefore, the declaration of a padding algo with the
external #ifdef is more readable and consistent.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
MD5 is being called directly in some places, but it is not available
via hash_lookup_algo("md5"). This is inconsistent with other hasing
routines. To resolve this, add an "md5" entry to hash_algos[].
The #ifdef clause looks funnier than those for other entries. This is
because both MD5 and SPL_MD5 configs exist, whereas the other hashes
do not have "SPL_" entries. The long term plan is to get rid of the
ifdefs, so those should not be expected to survive much longer.
The md5 entry does not have .hash_init/update/finish members. That's
okay because hash_progressive_lookup_algo() will catch that, and
return -EPROTONOSUPPORT, while hash_lookup_algo() will return the
correct pointer.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
[trini: Use CONFIG_IS_ENABLED not IS_ENABLED for MD5 check]
Signed-off-by: Tom Rini <trini@konsulko.com>
Originally CONFIG_FIT_SHAxxx enabled specific SHA algos for and only
for hash_calculate() in common/image-fit.c. However, since commit
14f061dcb1 ("image: Drop IMAGE_ENABLE_SHAxxx"),
the correct selector was changed to CONFIG_SHAxxx.
The extra "_FIT_" variants are neither used, nor needed. Remove them.
One defconfig disables FIT_SHA256, which is now changed to 'SHA256'.
CMD_MVEBU_BUBT needs to select select SHA256 to avoid undefined
references to "sha256_*()". bubt.c needs sha256, so this selection is
correct. It is not clear why this problem did not manifest before.
Note that SHA selection in SPL is broken for this exact reason. There
is no corresponding SPL_SHAxxx. Fixing this is is beyond the scope of
this change.
Also note that we make CONFIG_FIT now imply SHA256, to make up for
FIT_SHA256 previously being a default y option.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
[trini: Add imply SHA256 to FIT]
Signed-off-by: Tom Rini <trini@konsulko.com>
This macro is no longer needed for code flow or #ifdefs. Remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This macro is no longer needed for code flow or #ifdefs. Remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The purpose of this change is to enable crypto algorithms to be placed
in linker lists, rather than be declared as a static array. The goal
is to remove the crypto_algos array in a subsequent patch.
Create a new linker list named "cryptos", and search it when
image_get_crypto_algo() is invoked.
NOTE that adding support for manual relocation of crypto_algos within
linker lists is beyond the scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is not needed with Kconfig, since we can use IS_ENABLED() easily
enough. Drop it.
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>
We already have a host Kconfig for these SHA options. Use
CONFIG_IS_ENABLED(SHAxxx) directly in the code shared with the host build,
so we can drop the unnecessary indirections.
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>
