Instead of copying a GUID and then using a pointer to the copy for calling
guidcmp(), just pass the pointer to the orginal GUID.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We are ignoring the alignment communicated via the PE/COFF header.
Starting 5.10 the Linux kernel will loudly complain about it. For more
details look at [1] (in linux kernel).
So add a function that can allocate aligned EFI memory and use it for our
relocated loaded image.
[1] c32ac11da3f83 ("efi/libstub: arm64: Double check image alignment at entry")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When using a file to store UEFI variables we must make sure that secure
boot related variables are not loaded from this file. With commit
9ef82e2947 ("efi_loader: don't load signature database from file")
this has already been implemented for variables defined in the UEFI
specification. As most Linux distributions use Shim we should do the same
for Shim's MOK database.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This code should never have been added as it builds a new feature on top
of legacy code. This has already been improved with the dependency on BLK.
Add a dependency on DM_ETH also, to avoid needing to deal with this old
code.
Boards which want EFI_LOADER should migrate to driver model first.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Repeatedly receive the packets until the receive buffer is empty.
If the buffer is empty, EFI_SIMPLE_NETWORK_PROTOCOL::Receive()
returns EFI_NOT_READY. We don't need to use the wait_for_event()
every time.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT in packet
receiving loop. This depends on the implementation and not
related to whether the packet can be received or not.
Whether the received packets are available or not is ensured
by wait_for_packet, and that is already done in the loop.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
According to the UEF specification v2.9, the main purpose of the
EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() is for checking the link
status via EFI_SIMPLE_NETWORK_MODE::MediaPresent.
So this uses net->get_status() for checking the link status before
running network test.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The previous patches removed OF_PRIOR_STAGE from the last consumers of the
Kconfig option. Cleanup any references to it in documentation, code and
configuration options.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reserved memory nodes can have additional flags. Support reading and
writing these flags to ensure that reserved memory nodes can be properly
parsed and emitted.
This converts support for the existing "no-map" flag to avoid extending
the argument list for fdtdec_add_reserved_memory() to excessive length.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The fdtdec_set_carveout() function's parameters are inconsistent with
the parameters passed to fdtdec_add_reserved_memory(). Fix up the order
to make it more consistent.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reserved memory nodes can have a compatible string list to identify the
type of reserved memory that they represent. Support specifying an
optional compatible string list when creating these nodes.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
When retrieving a given carveout for a device, allow callers to query
the name. This helps differentiating between carveouts when there are
more than one.
This is also useful when copying carveouts to help assign a meaningful
name that cannot always be guessed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In order make it possible to use fdtdec_get_carveout() in loops, return
FDT_ERR_NOTFOUND when the passed-in index exceeds the number of phandles
present in the given property.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
At present U-Boot has a header file called lz4.h for its own use. If the
host has its own lz4 header file installed (e.g. from the 'liblz4-dev'
package) then host builds will use that instead.
Move the U-Boot file into its own directory, as is done with various
other headers with the same problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Convert pixel values when necessary like we do for 16bpp
framebuffers.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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>
At present EFI_SECURE BOOT selects RSA but does not necessarily enable
FIT_SIGNATURE. Mostly this is fine, but a few boards do not enable it,
so U-Boot tries to do RSA verification when loading FIT images, but it
is not enabled.
This worked because the condition for checking the RSA signature is
wrong in the fit_image_verify_with_data() function. In order to fix it
we need to fix this dependency. Make sure that FIT_SIGNATURE is enabled
so that RSA can be used.
It might be better to avoid using 'select' in this situation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a host Kconfig for CRC32. With this we can use CONFIG_IS_ENABLED(CRC32)
directly in the host build, so drop the unnecessary indirection.
Add a few more conditions to SPL_CRC32 to avoid build failures as well as
TPL_CRC32. Also update hash.c to make crc32 optional and to actually take
notice of SPL_CRC32.
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 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>
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>
Unfortunately these were removed by mistake. This means that adding hash
support to SPL brings in all software algorithms, with a substantial
increase in code size.
The origin of the problem was renaming them to SPL_FIT_xxx and then these
were removed altogether in a later commit.
Add them back. This aligns with CONFIG_MD5, for example, which has an SPL
variant.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: f5bc9c25f3 ("image: Rename SPL_SHAxxx_SUPPORT to SPL_FIT_SHAxxx")
Fixes: eb5171ddec ("common: Remove unused CONFIG_FIT_SHAxxx selectors")
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The gzip API uses the u64 type in it, which is not available in the host
build. This makes it impossible to include the header file.
We could make this type available, but it seems unnecessary. Limiting the
compression size to that of the 'unsigned long' type seems good enough. On
32-bit machines the limit then becomes 4GB, which likely exceeds available
RAM anyway, therefore it should be sufficient. On 64-bit machines this is
effectively u64 anyway.
Update the header file and implementation to use 'ulong' instead of 'u64'.
Add a definition of u32 for the cases that seem to need exactly that
length. This should be safe enough.
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing zstd API requires the same sequence of calls to perform its
task. Create a helper for U-Boot, to avoid code duplication, as is done
with other compression algorithms. Make use of of this from the image
code.
Note that the zstd code lacks a test in test/compression.c and this should
be added by the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
When passing a data buffer back from a function, it is not always clear
who owns the buffer, i.e. who is responsible for freeing the memory used.
An example of this is where multiple files are decompressed from the
firmware image, using a temporary buffer for reading (since the
compressed data has to live somewhere) and producing a temporary or
permanent buffer with the resuilts.
Where the firmware image can be memory-mapped, as on x86, the compressed
data does not need to be buffered, but the complexity of having a buffer
which is either allocated or not, makes the code hard to understand.
Introduce a new 'abuf' which supports simple buffer operations:
- encapsulating a buffer and its size
- either allocated with malloc() or not
- able to be reliably freed if necessary
- able to be converted to an allocated buffer if needed
This simple API makes it easier to deal with allocated and memory-mapped
buffers.
Signed-off-by: Simon Glass <sjg@chromium.org>
The CAAM on IMX7ULP doesn't support public key hardware acceleration
(PKHA), as in other NXP parts. Disable RSA_FREESCALE_EXP for IMX7ULP
too.
Fixed: f4e9ff7135 ("Kconfig: Don't use RSA_FREESCALE_EXP on IMX")
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
OEM_REVISION is 32-bit unsigned number. It should be increased only when
changing software version. Therefore it should not depend on build time.
Change calculation to use U-Boot version numbers and set this revision
to date number.
Prior this change OEM_REVISION was calculated from build date and stored in
the same format.
After this change macro U_BOOT_BUILD_DATE is not used in other files so
remove it from global autogenerated files and also from Makefile.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This config is only used by three boards with this SOC. Most other
platforms derive this information from devicetree, and are unlikely
to ever need this config.
Moreover, it is confusing when Kconfig asks for this value under
"Support OPTEE images", but does not do anything with the value.
Move it to imx7 for those boards who still make use of it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This value is not used by u-boot, and it should not. The load address
of an OPTEE image is defined by said image. Either a uImage or a FIT
will have a defined load address and entry point. Those values are the
correct ones, not CONFIG_OPTEE_LOAD_ADDR.
Commit f25006b96e ("optee: Add CONFIG_OPTEE_LOAD_ADDR") justifies
this config by requiring its presence in u-boot's .config for other
images as part of a larger build, claiming it is "the best way".
This argument is not persuasive. U-boot's configuration is driven by
platform requirements, not the other way around. It seems more likely
that the argument is conflating tooling issues with Kconfig. Yocto and
buildroot have excellent mechanisms for defining values across the
board (pun intended). u-boot's Kconfig is the wrong place to do it.
Furthermore, it is not "best" for u-boot because it hardcodes a value
which is then not used. In fact the load address that u-boot uses is
the one derived from the OPTEE image.
Confused yet? I sure was. To prevent future confusion, remove
CONFIG_OPTEE_LOAD_ADDR.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
It is no longer used in u-boot. Information about the TZDRAM location
is usually available in the devicetree as "/reserved-memory/" nodes.
Because this isn't used, remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The configs TZDRAM_BASE and TZDRAM_SIZE are expected to describe the
memory allocated to the OPTEE region. according to according to commit
c5a6e8bd00 ("optee: Add optee_verify_bootm_image()"). The TZDRAM is
with some limitations, described by "/reserved-memory" nodes in the
devicetree.
Consequently TZDRAM_BASE and TZDRAM_SIZE can point to imaginary
regions which have nothing to do with actual DRAM. They are not used
to configure the hardware or set up the Trust Zone Controller (TZC)
for OP-TEE -- the devicetree values are used instead.
When a valid OP-TEE image does not fall within the region described by
these configs, u-boot will refuse to load it. In fact, it mostly
serves to cause "bootm" to reject perfectly good OP-TEE images.
Ironically, someone has to correctly configure the devicetree for
TZDRAM, then go back and enter the same information in Kconfig for
"bootm". To remedy this, do not use TZDRAM_BASE and TZDRAM_SIZE in the
verification of OPTEE images.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The configuration CONFIG_OPTEE is defined 2 times:
1- in lib/optee/Kconfig for support of OPTEE images loaded by bootm command
2- in drivers/tee/optee/Kconfig for support of OP-TEE driver.
It is abnormal to have the same CONFIG define for 2 purpose;
and it is difficult to managed correctly their dependencies.
Moreover CONFIG_SPL_OPTEE is defined in common/spl/Kconfig
to manage OPTEE image load in SPL.
This definition causes an issue with the macro CONFIG_IS_ENABLED(OPTEE)
to test the availability of the OP-TEE driver.
This patch cleans the configuration dependency with:
- CONFIG_OPTEE_IMAGE (renamed) => support of OP-TEE image in U-Boot
- CONFIG_SPL_OPTEE_IMAGE (renamed) => support of OP-TEE image in SPL
- CONFIG_OPTEE (same) => support of OP-TEE driver in U-Boot
- CONFIG_OPTEE_LIB (new) => support of OP-TEE library
After this patch, the macro have the correct behavior:
- CONFIG_IS_ENABLED(OPTEE_IMAGE) => Load of OP-TEE image is supported
- CONFIG_IS_ENABLED(OPTEE) => OP-TEE driver is supported
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmFR2fMRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreaAnAf/ZKPy3CRphbgAmbLhNQhQGpLosLcFp343
cv53gfsv1DakLRrhqMSnOQSVoTg9P22uHbooDDR9WHfZyEL6tvGZ+dgN2/wlDhDj
wbvvsM7FB+uvLVfMF3MURQBvy4dPO+FyCm/uHmry2V2uqWPw4ss+aVhxeQ5s4/oI
LpS6yaiM8UAj2GTUZSqJ1+/W7YG9N6tL73n0PDyCvSrdCkyPWqpww1rtST88SfFI
bBEWc6ksna/29haOwHQ2xopEbVxtHv2byULfqUtnsbtE4Ozw8o0fx66tdwPHTQlM
7eSuRiEbqjlJuUZFIbMat7nb7inZkaWupZ/Sr1HUUiDdKMygrRsQhg==
=x8Uf
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-next-27sep21' of https://source.denx.de/u-boot/custodians/u-boot-dm into next
Various of-platdata improvements, including CONFIG_OF_REAL
The current API is outdated as it requires a devicetree pointer.
Move these functions to use the ofnode API and update this globally. Add
some tests while we are here.
Correct the call in exynos_dsim_config_parse_dt() which is obviously
wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
TCG EFI Protocol Specification defines the number_of_algorithms
field in spec ID event to be equal to the number of active
algorithms supported by the TPM device. In current implementation,
this field is populated with the count of all algorithms supported
by the TPM which leads to incorrect spec ID event creation.
Similarly, the algorithm array in spec ID event should be a variable
length array with length being equal to the number_of_algorithms field.
In current implementation this is defined as a fixed length array
which has been fixed.
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
CC: Masahisa Kojima <masahisa.kojima@linaro.org>
CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The arc/arm/m68k/microblaze/mips/ppc arch_lmb_reserve() implementations
are all mostly the same, except for a couple of details. Implement a
generic arch_lmb_reserve_generic() function which can be parametrized
enough to cater for those differences between architectures. This can
also be parametrized enough so it can handle cases where U-Boot is not
relocated to the end of DRAM e.g. because there is some other reserved
memory past U-Boot (e.g. unmovable firmware for coprocessor), it is not
relocated at all, and other such use cases.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Angelo Dureghello <angelo@sysam.it>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Hai Pham <hai.pham.ud@renesas.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wolfgang Denk <wd@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
ARMv8.0 has optional crc32 instruction for crc32 calculation. The
instruction is mandatory since ARMv8.1. The crc32 calculation is
faster using the dedicated instruction, e.g. 1.4 GHz iMX8MN gives:
=> time crc32 0x50000000 0x2000000
time: 0.126 seconds # crc32 instruction
time: 0.213 seconds # software crc32
Add implementation using the compiler builtin wrapper for the crc32
instruction and enable it by default, since we don't support any
platforms which do not implement this instruction.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Simon Glass <sjg@chromium.org>
[trini: Make crc32_table guarded by CONFIG_ARM64_CRC32]
Signed-off-by: Tom Rini <trini@konsulko.com>
This was unfortunately applied despite much discussion about it beiong
the wrong way to implement this feature.
Revert it before too many other things are built on top of it.
This reverts commit ddf67daac3.
Signed-off-by: Simon Glass <sjg@chromium.org>
Header file version.h does not use anything from timestamp.h. Including of
timestamp.h has side effect which cause recompiling object file at every
make run because timestamp.h changes at every run.
So remove timestamp.h from version.h and include timestamp.h in files
which needs it.
This change reduce recompilation time of final U-Boot binary when U-Boot
source files were not changed as less source files needs to be recompiled.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Add in lib/acpi/acpi_table.c and test/dm/acpi.c, rework a few others]
Signed-off-by: Tom Rini <trini@konsulko.com>
More C files do not use compile time timestamp macros and do not have to be
recompiled every time when SOURCE_DATE_EPOCH changes.
This patch moves version_string[] from version.h to version_string.h and
updates other C files which only needs version_string[] string to include
version_string.h instead of version.h. After applying this patch these
files are not recompiled every time when SOURCE_DATE_EPOCH changes.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Macro U_BOOT_VERSION_STRING is already stored in variable version_string.
So use directly this variable instead of storing U_BOOT_VERSION_STRING into
temporary variable.
Signed-off-by: Pali Rohár <pali@kernel.org>
[trini: This area was reworked since posted, what is here is now really
inspired by the previous version, so drop Ilias' Acked-by]
Signed-off-by: Tom Rini <trini@konsulko.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>
There are trivial typos in the Kconfig file. Fixed them.
Also, fixed grammar in the descriptions with typos.
Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and CMD_UBIFS")
Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If keydir is not provided but name is we want to use name as key_id.
But with the current coding name is only used on its own if it is NULL
and keydir is provided which never occurs.
Fixes: 824ee745fb ("lib/rsa: Use the 'keyfile' argument from mkimage")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
We don't need this check anymore since when PCI is enabled, driver model
is always used.
Sadly this doesn't work with nds32 for some reason to do with the
toolchain. Add a work-around for that.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is two unneeded EFI_CALL references in tcg2_measure_pe_image().
The first one in efi_search_protocol() and the second on in the device path
calculation. The second isn't even a function we should be calling, but a
pointer assignment, which happens to work with the existing macro.
While at it switch the malloc call to a calloc, remove the unnecessary cast
and get rid of an unneeded if statement before copying the device path
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The move to driver model should by now be completed. To be able to remove
pre-driver model code from our block IO code require CONFIG_BLK=y for UEFI
support.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
boot_service_capability_min is constant, it should be capitalized.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When dropping SHA512_ALGO in general, we didn't catch some cases where
an option was selecting both SHA512 and SHA512_ALGO and caused them to
select SHA512 twice. Kconfig doesn't complain, but this is still wrong
and should be corrected.
Fixes: e60e449931 ("lib: Drop SHA512_ALGO in lieu of SHA512")
Reported-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.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>
All of these configs exist. Stick to using CONFIG_[ST]PL_HASH, and drop all
references to CONFIG_[ST]PL_HASH_SUPPORT. This means we need for
CHAIN_OF_TRUST to select SPL_HASH now.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
[trini: Add TPL case, fix CHAIN_OF_TRUST, other tweaks]
Signed-off-by: Tom Rini <trini@konsulko.com>
SHA512_ALGO was used as a "either SHA512 or SHA384", although the
implementations of these two algorithms share a majority of code.
From a Kconfig interface perspective, it makes sense to present two
distinct options. This requires #ifdefing out the SHA512
implementation from sha512.c. The latter doesn't make any sense.
It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
seems to be the more polite way to handle the selection.
Thus, automatically select SHA512 when SHA384 is enabled.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
TCG EFI Protocol Specification defines that PCRIndex parameter
passed from caller must be 0 to 23.
TPM2_MAX_PCRS is currently used to check the range of PCRIndex,
but TPM2_MAX_PCRS is tpm2 device dependent and may have larger value.
This commit newly adds EFI_TCG2_MAX_PCR_INDEX macro, it is used to
check the range of PCRIndex parameter.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
TCG EFI Protocol Specification defines the required parameter
checking and return value for each API.
This commit adds the missing parameter check and
fixes the wrong return value to comply the specification.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When U-Boot is started we have to use the existing variables to determine
in which secure boot state we are.
* If a platform key PK is present and DeployedMode=1, we are in deployed
mode.
* If no platform key PK is present and AuditMode=1, we are in audit mode.
* Otherwise if a platform key is present, we are in user mode.
* Otherwise if no platform key is present, we are in setup mode.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Writing variables AuditMode and DeployedMode serves to switch between
Secure Boot modes. Provide a separate value for these in efi_auth_var_type.
With this patch the variables will not be read from from file even if they
are marked as non-volatile by mistake.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The UEFI specification requires that the signature database may only be
stored in tamper-resistant storage. So these variable may not be read
from an unsigned file.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We should not first allocate memory and then report a rounded up value as
image size. Instead first round up according to section allocation and then
allocate the memory.
Fixes: 82786754b9 ("efi_loader: ImageSize must be multiple of SectionAlignment")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In a section header VirtualSize may be zero. This is for instance seen in
the .sbat section of shim. In this case use SizeOfRawData as section size.
Fixes: 9d30a941cc ("efi_loader: don't load beyond VirtualSize")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Asherah Connor <ashe@kivikakk.ee>
CONFIG_MMC_SPI_CRC_ON needs the crc16 functions, but it was not included
in an SPL build. For non-SPL builds, crc16.o is already added
unconditionally. This also removes CONFIG_SPL_YMODEM_SUPPORT from the
sifive board configs, which is only relevant for some ARM boards and was
only set for its side effect of adding crc16.o.
With glibc 2.33 (Ubuntu package glibc6 2.33-0ubuntu9) building
sifive_unmatched_defconfig results in:
In file included from /usr/include/stdio.h:866,
from ././include/compiler.h:26,
from <command-line>:
In function ‘snprintf’,
inlined from ‘rsa_engine_get_priv_key’ at ./tools/../^:273:4:
/usr/include/riscv64-linux-gnu/bits/stdio2.h:71:10: warning:
‘%s’ directive argument is null [-Wformat-truncation=]
71 | return __builtin___snprintf_chk (__s, __n,
__USE_FORTIFY_LEVEL - 1,
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
72 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
73 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
Avoid passing a NULL string.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Older OpenSSL and libressl versions have a slightly different API.
This require #ifdefs to support. However, we still can't support it
because the ECDSA path does not compile with these older versions.
These #ifdefs are truly a vestigial appendage.
Alternatively, the ECDSA path could be updated for older libraries,
but this requires significant extra code, and #ifdefs. Those libraries
are over three years old, and there concerns whether it makes sense to
build modern software for real world use against such old libraries.
Thusly, remove #ifdefs and code for old OpenSSL and LibreSSL support.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
Documentation:
* Rename Freescale to NXP
* Document structures used for the UEFI TCG2 protocol
UEFI:
* Device paths must use EfiBootServicesData
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmEf+AgACgkQhO4vgnE3
U0skxhAAjjv6yMYLYlj2YNTtYDS2zVsnsY8i/vmWNmGYvwfrlcUC/e3J00ftBIjI
DEwImrzefvQwr4NOZgIlyxR81NwboWULxvHSF5avwctxQVoTElkSfE2Ji+nFYa23
P/L7E/Zf+NwTHBlE1wfkNJPZ/zya73DTOe+MGWvLnvOX56JZqEJOgmTtcQntRUll
9zkB76j6sCk8B3ydFZmzGqhB4aslJBypG+bQB72XXGVBZoHb9pEPv90hBl616AN/
5H8WewxTE2s6z3IfexxPAc7ssMQuW3RWw0WsJvBVviw8tSPj4SZjg5HNHAM3mz/i
EXHUqAEySP1oT6P4hVef7Xc9gC67N+dVZGAA1QcZBkAnH+BQQ2GmIWX5+3mZJflq
3eHWhMUHWc4q76MbN9QqReAo3wJ3GsBqdA1oORR5FgIPwEVl0jwQMYv6frC/vB6/
6VX8WcbAWsixjf8QeQlibfMqBO9xZI1Iue5rN6DcwMey6dZrDnXGMdk7Woj6F4ga
tERYBt+UBawTf2ww24wMXc7Hw2dZ6kj44ls2doRFKqHOpaY9Mk2QPTaVPrFkj33J
3xlH2BYdB3ALriS1jN6Qcq6xEwyaMdkj5MzVyitunaCLiAKKORwGf0chkqiRiA+k
zEET0uDBtO7beraiUJU9jeMPcVj3mYpiFR/CZBD/HWOVB/KwhGU=
=gMKg
-----END PGP SIGNATURE-----
Merge tag 'efi-2021-10-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2021-10-rc3
Documentation:
* Rename Freescale to NXP
* Document structures used for the UEFI TCG2 protocol
UEFI:
* Device paths must use EfiBootServicesData
tiny-printf variant doesn't know how to handle %llu format string, but both
tiny-printf and print_size can meet in SPL when TFTP is used to obtain main
u-boot image. This is known to lead to critical boot issue at AM335x platform
when printf is catched in infinite loop.
To avoid such issues and make print_size function tiny-printf friendly, use %u
instead of %luu. Note, that the size value is guaranteed to be less than 1024
in this conditional branch, so the cast to unsigned int is safe.
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
%pM format string is used to print MAC-address and this is required while SPL
network boot.
This patch fixes the SPL boot issues like the following:
Trying to boot from USB eth
## Error: flags type check failure for "ethaddr" <= "40309614M" (type: m)
## Error inserting "ethaddr" variable, errno=1
eth0: eth_cpsw## Error: flags type check failure for "eth1addr" <=
"81f01114M" (type: m)
## Error inserting "eth1addr" variable, errno=1
, eth1: usb_ether
eth_cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Memory allocated in the implementation of the
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL must be of type EfiBootServicesData.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
dp_alloc() was using a constant from the wrong enum resulting in creating
device paths in EfiReservedMemory.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Use enum efi_memory_type and enum_allocate_type in the definitions of the
efi_allocate_pages(), efi_allocate_pool().
In the external UEFI API leave the type as int as the UEFI specification
explicitely requires that enums use a 32bit type.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Implement the crypto_algo .verify() function for ecdsa256. Because
it backends on UCLASS_ECDSA, this change is focused on parsing the
keys from devicetree and passing this information to the specific
UCLASS driver.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Refactor efi_append_scrtm_version() to use common
function for adding eventlog and extending PCR.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
TCG PC Client PFP spec requires to measure
"Exit Boot Services Invocation" if ExitBootServices() is invoked.
Depending upon the return code from the ExitBootServices() call,
"Exit Boot Services Returned with Success" or "Exit Boot Services
Returned with Failure" is also measured.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Swap two ifs in efi_exit_boot_services().
efi_tcg2_notify_exit_boot_services must have EFIAPI signature.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
TCG PC Client PFP spec requires to measure "Boot####"
and "BootOrder" variables, EV_SEPARATOR event prior
to the Ready to Boot invocation.
Since u-boot does not implement Ready to Boot event,
these measurements are performed when efi_start_image() is called.
TCG spec also requires to measure "Calling EFI Application from
Boot Option" for each boot attempt, and "Returning from EFI
Application from Boot Option" if a boot device returns control
back to the Boot Manager.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
TCG PC Client PFP spec requires to measure the secure
boot policy before validating the UEFI image.
This commit adds the secure boot variable measurement
of "SecureBoot", "PK", "KEK", "db", "dbx", "dbt", and "dbr".
Note that this implementation assumes that secure boot
variables are pre-configured and not be set/updated in runtime.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
iPXE used Uri() device path nodes. So we should support them in the
device path to text protocol.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
U-Boot mostly uses hex for value input, largely because addresses are much
easier to understand in hex.
But in some cases a decimal value is requested, such as where the value is
small or hex does not make sense in the context. In these cases it is
sometimes useful to be able to provide a hex value in any case, if only to
resolve any ambiguity.
Add this functionality, for increased flexibility.
Signed-off-by: Simon Glass <sjg@chromium.org>
The code to convert a character into a digit is repeated twice in this
file. Factor it out into a separate function. This also makes the code a
little easier to read.
Signed-off-by: Simon Glass <sjg@chromium.org>
If we see 0x then we can assume this is the start of a hex value. It
does not seem necessary to check for a hex digit after that since it will
happen when parsing the value anyway.
Drop this check to simplify the code and reduce size. Add a few more test
cases for when a 0x prefix is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
CONFIG_HEXDUMP is needed to display UEFI variables using 'printenv -e'.
Enabling CONFIG_SPL_HEXDUMP only makes sense for debugging purposes.
Hence CONFIG_SPL_HEXDUMP should not be enabled by default.
The following boards currently have CONFIG_SPL_HEXDUMP=y. This includes
boards that don't use SPL at all.
axm_defconfig
imx8mm-cl-iot-gate_defconfig
imx8mm_venice_defconfig
imxrt1020-evk_defconfig
imxrt1050-evk_defconfig
kontron_sl28_defconfig
kp_imx53_defconfig
lx2160ardb_tfa_stmm_defconfig
mt7622_rfb_defconfig
octeon_ebb7304_defconfig
octeon_nic23_defconfig
qemu_arm64_defconfig
qemu_arm_defconfig
qemu-riscv32_defconfig
qemu-riscv32_smode_defconfig
qemu-riscv64_defconfig
qemu-riscv64_smode_defconfig
qemu-x86_64_defconfig
qemu-x86_defconfig
sandbox64_defconfig
sandbox_defconfig
stm32mp15_basic_defconfig
stm32mp15_trusted_defconfig
synquacer_developerbox_defconfig
taurus_defconfig
xilinx_versal_virt_defconfig
The patch only keeps it enabled on
sandbox_spl_defconfig
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This patch adds the possibility to pass the PIN the OpenSSL Engine
used during signing via the environment variable MKIMAGE_SIGN_PIN.
This follows the approach used during kernel module
signing ("KBUILD_SIGN_PIN") or UBIFS image
signing ("MKIMAGE_SIGN_PIN").
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
*sig_size isn't set until later so use the correct variables.
Signed-off-by: Donald Chan <hoiho@lab126.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rather than looking at two KConfig options in the Makefile, create a new
Kconfig option for compiling lib/charset.c
Enable it for UFS also, which needs this support.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add simple_strtoll function for converting a string containing digits
into a long long int value.
Signed-off-by: Roland Gaudig <roland.gaudig@weidmueller.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a bus driver for this and use it to configure the bus parameters for
the Ethernet interface. Drop the old pre-driver-model code.
Switch over to use driver model for Ethernet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
In the commit c982874e93 ("efi_loader: refactor
efi_setup_loaded_image()"), setjmp-related definitions were moved to
efi_loaded_image_obj in efi_loader.h. So setjmp.h is no longer
refererenced in efi_api.h.
This also fixes some error when efi_api.h will be included in
mkeficapsule.c.
Fixes: c982874e93 ("efi_loader: refactor efi_setup_loaded_image()")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If capsule authentication is disabled and yet a capsule file is signed,
its signature must be removed from image data to flush.
Otherwise, the firmware will be corrupted after update.
Fixes: 04be98bd6b ("efi: capsule: Add support for uefi capsule
authentication")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
efi_guid_capsule_root_cert_guid is never used.
Just remove it.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
SMBIOS tables only support 32bit addresses. If we don't have memory here
handle the error gracefully:
* on x86_64 fail to start U-Boot
* during UEFI booting ignore the missing table
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
BIOS Release Date must be in format mm/dd/yyyy and must be release date.
U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
generated from current build timestamp.
Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
better approximation of U-Boot release date than current build timestamp.
Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
Some operating systems are using BIOS Release Date for detecting when was
SMBIOS table filled or if it could support some feature (e.g. BIOS from
1990 cannot support features invented in 2000). So this change also ensures
that recompiling U-Boot from same sources but in different year does not
change behavior of some operating systems.
Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
so remove it from global autogenerated files and also from Makefile.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
In order to prevent using the global errno, replace it with a static
version and create a wrapper function which returns the error value.
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add the basic functionality required to support the standard crypt
format.
The files crypt-sha256.c and crypt-sha512.c originate from libxcrypt and
their formatting is therefor retained.
The integration is done via a crypt_compare() function in crypt.c.
```
libxcrypt $ git describe --long --always --all
tags/v4.4.17-0-g6b110bc
```
Signed-off-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
The capsule signature is now part of our DTB. This is problematic when a
user is allowed to change/fixup that DTB from U-Boots command line since he
can overwrite the signature as well.
So Instead of adding the key on the DTB, embed it in the u-boot binary it
self as part of it's .rodata. This assumes that the U-Boot binary we load
is authenticated by a previous boot stage loader.
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
TCG PC Client PFP spec says "The Log Area Minimum Length
for the TCG event log MUST be at least 64KB." in ACPI chapter.
This commit increase the buffer size to 64KB.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Use %pD to log device-path instead of using efi_dp_str() and
efi_free_pool() locally in find_boot_device().
This is a cleanup patch, no feature update nor fix.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Previously, the GPT device GUID was being used instead of the partition,
which was incorrect.
Signed-off-by: Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com>
Let EFI_LOADER select CONFIG_PARTITION_UUIDS.
Use log_warning() instead of printf() for warning.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Move the RSA verification crytpo_algo structure out of the
crypto_algos array, and into a linker list.
Although it appears we are adding an #ifdef to rsa-verify.c, the gains
outweigh this small inconvenience. This is because rsa_verify() is
defined differently based on #ifdefs. This change allows us to have
a single definition of rsa_verify().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
There's currently no user of %p[iI]6, so including ip6_addr_string()
in the image is a waste of bytes. It's easy enough to have the
compiler elide it without removing the code completely.
The closest I can find to anybody "handling" ipv6 in U-Boot currently
is in efi_net.c which does
if (ipv6) {
ret = EFI_UNSUPPORTED;
As indicated in the comment, it can easily be put back, but preferably
under a config knob.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
U-Boot doesn't support %pS/%pF or any other kind of kallsyms-like
lookups. Remove the comment.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
This saves some code, both in terms of #LOC and .text size, and it is
also the normal convention that foo(...) is implemented in terms of
vfoo().
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
In tpm_sendrecv_command() the command buffer is passed in. If a mistake is
somehow made in setting this up, the size could be out of range. Add a
sanity check for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Coverity (CID: 331152)
Function rtc_to_tm() is needed for FAT file system support even if we don't
have a real time clock. So move it from drivers/ to lib/.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Fix find_boot_device() to set bootdev_root if it finds the
bootdev from BootNext. Currently it sets the bootdev_root only
when it finds bootdev from BootOrder.
Fixes: c74cd8bd08 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Accked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If multiple capsules are applied, the FMP drivers for the individual
capsules can expect the value of CapsuleLast to be accurate. Hence
CapsuleLast must be updated after each capsule.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
* Use log category LOGC_EFI. This allows to remove 'EFI:' prefixes in
messages.
* Rephrase some of the messages.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When reading a directory using EFI_FILE_PROTOCOL.Read() provide file
attributes and timestamps.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.
Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.
Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: apalos <ilias.apalodimas@linaro.org>
Reword Kconfig description.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
After each reboot we must clear flag
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
OsIndications.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Reported-by: Kazuhiko Sakamoto <sakamoto.kazuhiko@socionext.com>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
After if we should use parentheses to keep the code readable.
Fixes: a95f4c8859 ("efi_loader: NULL dereference in EFI console")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We only install FMPs if a CapsuleUpdate is requested. Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Chapter 23 of the EFI spec (rev 2.9) says:
"A specific updatable hardware firmware store must be represented by
exactly one FMP instance".
This is not the case for us, since both of our FMP protocols can be
installed at the same time because they are controlled by a single
'dfu_alt_info' env variable.
So make the config options depend on each other and allow the user to
install one of them at any given time. If we fix the meta-data provided
by the 'dfu_alt_info' in the future, to hint about the capsule type
(fit or raw) we can revise this and enable both FMPs to be installed, as
long as they target different firmware hardware stores
Note that we are not using a Kconfig 'choice' on purpose, since we
want to allow both of those to be installed and tested in sandbox
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
This is because the code passes efi_root instead of the handle local var.
=> efidebug capsule disk-update
EFI: Call: efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbaf5988)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbaf5988, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6ee8)
EFI: new handle 00000000fbb37520
EFI: Exit: efi_install_protocol_interface: 0
EFI: 0 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 0
EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbfec648)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbfec648, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6f18)
EFI: handle 00000000fbaf8520
EFI: Exit: efi_install_protocol_interface: 2
EFI: 2 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 2
EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
Command failed, result=1
To fix this issue, pass the handle local var which is set NULL right
before installing efi_fmp_raw as same as the installing efi_fmp_fit.
(In both cases, the local reference to the handle will be just discarded)
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Documentation:
* man-page for askenv
bug fixes
* correct display of BootOrder in efidebug command
* do not allow TPL_HIGH_LEVEL for CreateEvent(Ex)
* correct handling of unknown properties in SMBIOS tables
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmDaDcEACgkQxIHbvCwF
GsTjZQ//elKP0sKZYEMePzOZKZfzD0MnjnzTwsWALqA9h8kv1sAvQLtf5ZDXWIci
bo4PNhgRD+FHQuprdoLUrQ2+fSNKTUZugmz8lW1Yudiyh+W4oyjYfINRx+gLTH8L
h5W8w5QkV0R+3Ti8U42YYj+SqsUs0htGW5b2k55kZhH0uUFB63GG2ic0KkHr9cHl
QQ3Y3tnW+PMxNaer5Q6q3DQjnPTnTO6vfwD9VAoesTd4aunlaPEvK7xAObJzxjpQ
ySrj0+Yw4S+y0+02eZRnHXgAIZgI73aN2LiiSuT+FrgGN6JPmVlT6ey3LqLCxPDP
VcEF8S25ULoIu7G7ZgIzzVgbvDjWU9WZNduPU3onVfqT2RaSsRPZoVdyGty+EKRi
At40vUsAjC3TkttuhDZhfOOoM3ot9vEeeTIQ5Po7bnwwJyMT+PfUTi7PJT/vkfqy
iN3KHCi0vuzxS/TbpV9ivrFnMdBP6g6v602VgeMeUTEvHFO9xAA3rHYqFQT7qNxH
4IrRAma6t0R//oeQ5DKD3iqFdkoireHkobEJh0o3hRK7nDAenZiRmvec+o/iogKV
YO+lZMboz5igAITBlJI5QoifGDs9B1DwoKxUe9dW61jA1CE7qqGg9Qvo251DZ8Ce
6f8RLkglAkJUbgotyq/YGRRfad28KISEMewj8ATxbQWRCK2vSNQ=
=ZMB2
-----END PGP SIGNATURE-----
Merge tag 'efi-2021-07-rc5-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2021-07-rc5-2
Documentation:
* man-page for askenv
bug fixes
* correct display of BootOrder in efidebug command
* do not allow TPL_HIGH_LEVEL for CreateEvent(Ex)
* correct handling of unknown properties in SMBIOS tables
If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled,
wherever original env is placed anywhere, it should be relocated to
the right address.
Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in
setup_reloc() and env address gd->env_addr is relocated by the offset in
initr_reloc_global_data().
gd->env_addr
= (orig env) + gd->reloc_off
= (orig env) + (gd->relocaddr - SYS_TEXT_BASE)
However, SYS_TEXT_BASE isn't always runtime base address when
POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to
wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is
out of memory location and memory exception will occur.
There is a difference between linked address such as SYS_TEXT_BASE and
runtime base address. In _main, the difference is calculated as
"run-vs-link" offset. The env_addr should also be added to the offset
to fix the address.
gd->env_addr
= (orig env) + ("run-vs-link" offset) + gd->reloc_off
= (orig env) + (SYS_TEXT_BASE - _start) + (gd->relocaddr - SYS_TEXT_BASE)
= (orig env) + (gd->relocaddr - _start)
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Commit e4f8e543f1a9("smbios: Drop the unused Kconfig options")
break SMBIOS tables. The reason is that the patch drops the Kconfig
options *after* removing the code using them, but that changes the semantics
of the code completely. Prior to the change a non NULL value was used in
the 'product' and 'manufacturer ' fields.
Chapter 6.2 of the DMTF spec requires Manufacturer and Product Name to be
non-null on some of the tables. So let's add sane defaults for Type1/2/3.
* Before the patchset:
<snip>
Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
Manufacturer: Not Specified
Product Name: Not Specified
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Features:
Board is a hosting board
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Motherboard
Invalid entry length (0). DMI table is broken! Stop.
* After the patchset:
<snip>
Handle 0x0005, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0006, DMI type 127, 4 bytes
End Of Table
Fixes: e4f8e543f1 ("smbios: Drop the unused Kconfig options")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We currently define the EFI support of an SMBIOS table as the third bit of
"BIOS Characteristics Extension Byte 1". The latest DMTF spec defines it
on "BIOS Characteristics Extension Byte 2".
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Remove superfluous assignment.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
According to chapter 7.1 "Event, Timer, and Task Priority Services"
TPL_HIGH_LEVEL should not be exposed to applications and drivers.
According to the discussion with EDK II contributors this implies that
CreateEvent() shall not allow to create events with TPL_HIGH_LEVEL.
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Copy the best rational approximation calculation routines from Linux.
Typical usecase for these routines is to calculate the M/N divider
values for PLLs to reach a specific clock rate.
This is based on linux kernel commit:
"lib/math/rational.c: fix possible incorrect result from rational
fractions helper"
(sha1: 323dd2c3ed0641f49e89b4e420f9eef5d3d5a881)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tero Kristo <kristo@kernel.org>
Brackets '[' need to be escaped to avoid a build warning
lib/efi_loader/efi_image_loader.c:223:
WARNING: Inline strong start-string without end-string.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Masahisa Kojima <masahisa.kojima@linaro.org>
If we want to address partition 15 of virtio block device 11, we have to
write:
virtio b:f
When calling sprintf() we must use %x for the device and partition numbers.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
At present print_buffer() outputs a hex dump but it is not possible to
place this dump in a string. Refactor it into a top-level function which
does the printing and a utility function that dumps a line into a string.
This makes the code more generally useful.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present print_hex_dump() only supports either 16- or 32-byte lines.
With U-Boot we want to support any line length up to a maximum of 64.
Update the function to support this, with 0 defaulting to 16, as with
print_buffer().
Signed-off-by: Simon Glass <sjg@chromium.org>
The current implementation outputs an address as a pointer. Update the
code to use an address instead, respecting the 32/64 nature of the CPU.
Add some initial tests copied from print_test_display_buffer(), just the
ones that can pass with the current implementation.
Note that for this case print_hex_dump() and print_bufffer() produce the
same result. For now the tests are duplicated sine we have separate
functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the comments to the header file so people can find the function info
without digging in the implementation. Fix up the code style and add an
enum for the first arg.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present with print_buffer() U-Boot shows four spaces between the hex
and ASCII data. Two seems enough and matches print_hex_dump(). Change it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new function lmb_is_reserved_flags to check if
an address is reserved with a specific flags.
This function can be used to check if an address was
reserved with no-map flags with:
lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add "flags" in lmb_property to save the "no-map" property of
reserved region and a new function lmb_reserve_flags() to check
this flag.
The default allocation use flags = LMB_NONE.
The adjacent reserved memory region are merged only when they have
the same flags value.
This patch is partially based on flags support done in Linux kernel
mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is
aligned with MEMBLOCK_NOMAP value.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If a chunk was larger than 4GiB, then chunk_data_sz would overflow and
blkcnt would not be calculated correctly. Upgrade it to a u64 and cast
its multiplicands as well. Also fix bytes_written while we're at it.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
"TCG PC Client Platform Firmware Profile Specification"
requires to measure every attempt to load and execute
a OS Loader(a UEFI application) into PCR[4].
This commit adds the PE/COFF image measurement, extends PCR,
and appends measurement into Event Log.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Replace CONFIG_HASH_CALCULATE by CONFIG_HASH
Fix conversions between pointers and u64.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The hash_calculate() symbol is provided by hash-checksum.c. It depends
on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y.
The issue is that hash_calculate() is used by the efi_loader,
irregardless of CONFIG_FIT_SIGNATURE. As pointed out in
commit 87316da05f ("lib: introduce HASH_CALCULATE option"),
enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect.
To resolve this, use CONFIG_HASH as the compile switch for
hash-checksum.c. This ensures that all dependencies are compiled, and
is the most natural Kconfig to use.
There is the issue of having to 'select HASH' in a couple of places
that already 'select SHA256'. This is a deeper problem with how hashes
are organized, and fixing it is beyonf the scope of this change.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
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>
Coverity reported 3 warnings on the current code.
CID 331856, 331855, 331854 on the latest scan.
Fix the rest of the warnings by initializing the variables before
passing them to tpm2_get_pcr_info().
In order to avoid future warnings and errors initialize them to 0 within
the function as well, since the values are always OR'ed after querying the
hardware.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Compiling with -Wextra produces a number of (harmless) warnings for the EFI
TCG2 protocol. Let's fix those in case we ever enable the flag on the EFI
subsystem
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Before this patch efi_dp_from_name() only accommodated a maximum file path
length of 31 characters. This leads to boot failures due to file name
truncation.
Allow arbitrary path lengths.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This is preparation for PE/COFF measurement support.
PE/COFF image hash calculation is same in both
UEFI Secure Boot image verification and measurement in
measured boot. PE/COFF image parsing functions are
gathered into efi_image_loader.c, and exposed even if
UEFI Secure Boot is not enabled.
This commit also adds the EFI_SIGNATURE_SUPPORT option
to decide if efi_signature.c shall be compiled.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Configuring a system with CONFIG_EFI_CAPSULE_AUTHENTICATE=y but without a
method to retrieve the public key data is a misconfiguration. We should get
a build failure for it. Therefore remove the weak efi_get_public_key_data()
implementation.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When building with LTO, the system libc's `errno` variable used in
arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
lib/errno.c) with the following error:
.../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6
section .tbss mismatches non-TLS reference in
/tmp/u-boot.EQlEXz.ltrans0.ltrans.o
To avoid this conflict use different asm label for this variable when
CONFIG_SANDBOX is enabled.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When compiling with LTO, the compiler fails with an error saying that
`crc_table` causes a section type conflict with `efi_var_buf`.
This is because both are declared to be in the same section (via macro
`__efi_runtime_data`), but one is const while the other is not.
Put this variable into the section .rodata.efi_runtime, instead of
.data.efi_runtime, via macro __efi_runtime_rodata.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heinrich Schuchardt <xypron.gpk@gmx.de>
Add $(CFLAGS_EFI) and remove $(CFLAGS_NON_EFI) for
efi_selftest_miniapp_exception.o.
The removal is needed when compiling with LTO - this object file needs
to be compiled without -flto.
The adding is for consistency with other miniapps.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
It seems that sometimes (happening on ARM64, for example with
turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
names of some functions, for example lib/string.c's memcpy() function to
memcpy.isra.0.
This is a problem however when GCC for a code such as this:
struct some_struct *info = get_some_struct();
struct some struct tmpinfo;
tmpinfo = *info;
emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo.
This then results in the following linking error:
.../lz4.c:93: undefined reference to `memcpy'
.../uuid.c:206: more undefined references to `memcpy' follow
GCC's documentation says this about -nodefaultlibs option:
The compiler may generate calls to "memcmp", "memset", "memcpy" and
"memmove". These entries are usually resolved by entries in libc.
These entry points should be supplied through some other mechanism
when this option is specified.
Make these functions visible by using the __used macro to avoid this
error.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit does the same thing as Linux commit 33def8498fdd.
Use a more generic form for __section that requires quotes to avoid
complications with clang and gcc differences.
Remove the quote operator # from compiler_attributes.h __section macro.
Convert all unquoted __section(foo) uses to quoted __section("foo").
Also convert __attribute__((section("foo"))) uses to __section("foo")
even if the __attribute__ has multiple list entry forms.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Generally speaking BINMAN_FDT makes sense for OF_SEPARATE or OF_EMBED.
For the other OF_CONTROL methods, it's quite possible binman node is
not available as binman is invoked during the build phase instead of
runtime. Let's only turn it on for OF_SEPARATE or OF_EMBED by default.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
EFI_TCG2 depends not only on TPMv2 but also on the underlying algorithms.
So select the missing SHA1, SHA256, SHA384 and SHA512 we currently support
Reported-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add 'default y'.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Up to now we are stopping the EFI subsystem if a TPMv2 exists but the
protocol fails to install. Now that we've switched the config to 'default
y' the sandbox TPM fails, since it doesn't support all the required
capabilities of the protocol.
Not installing the protocol is not catastrophic. If the protocol fails
to install the PCRs will never be extended to the expected values, so
some other entity later in the boot flow will eventually figure it out
and take the necessary actions.
While at it fix a corner case were the user can see an invalid error
message when the protocol failed to install. We do have a tcg2_uninit()
which we call when the protocol installation fails. There are cases though
that this might be called before the configuration table is installed (e.g
probing the TPM for capabilities failed). In that case the user will see
"Failed to delete final events config table". So stop printing it since it's
not an actual failure , simply because the config table was never installed
in the first place.
In order to stop printing it make efi_init_event_log() and create_final_event()
cleanup themselves and only call tcg2_uninit() when the protocol installation
fails.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Instead of just failing, clean up the installed config table and
EventLog memory if logging an s-crtm event fails during the protocol
installation
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Eliminate label 'out:' by using return.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_init_event_log() calls tcg2_uninit() in case of failure.
We can skip that since the function is called on efi_tcg2_register()
which also cleans up if an error occurs
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This is same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1733817,
but that fix was wrongly partial reverted.
When reading a directory, EFI_BUFFER_TOO_SMALL should be returned when
the supplied buffer is too small, so a use-case is to call
EFI_FILE_PROTOCOL.Read() with *buffer_size=0 and buffer=NULL to
obtain the needed size before doing the actual read.
So remove the check only for directory reading, file reading already
do the check by itself.
Fixes: db12f518edb0("efi_loader: implement non-blocking file services")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefan Sørensen <stefan.sorensen@spectralink.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The current capsule authentication code checks if the environment
variable capsule_authentication_enabled is set, for authenticating the
capsule. This is in addition to the check for the config symbol
CONFIG_EFI_CAPSULE_AUTHENTICATE. Remove the check for the environment
variable. The capsule will now be authenticated if the config symbol
is set.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviwed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Commit a479f103dc ("hash: Allow for SHA512 hardware implementations")
defined function definitions for hardware accelerated SHA384 and SHA512.
If CONFIG_SHA_HW_ACCEL=y, these functions are used.
We already have boards using CONFIG_SHA_HW_ACCEL=y but none implements the
new functions hw_sha384() and hw_sha512().
For implementing the EFI TCG2 protocol we need SHA384 and SHA512. The
missing hardware acceleration functions lead to build errors on boards like
peach-pi_defconfig.
Introduce a new Kconfig symbol CONFIG_SHA512_HW_ACCEL to control if the
functions hw_sha384() and hw_sha512() shall be used to implement the SHA384
and SHA512 algorithms.
Fixes: a479f103dc ("hash: Allow for SHA512 hardware implementations")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Building 32bit boards with the TCG2 protocol enabled leads to a build
warning due to a missing conversion.
lib/efi_loader/efi_tcg2.c:774:27:
error: cast to pointer from integer of different size
[-Werror=int-to-pointer-cast]
774 | ret = tcg2_create_digest((u8 *)data_to_hash, data_to_hash_len,
| ^
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Today of_address_to_resource() is called only in
ofnode_read_resource() for livetree support and
fdt_get_resource() is called when livetree is not supported.
The fdt_get_resource() doesn't do the address translation
so when it is required, but the address translation is done
by ofnode_read_resource() caller, for example in
drivers/firmware/scmi/smt.c::scmi_dt_get_smt_buffer() {
...
ret = ofnode_read_resource(args.node, 0, &resource);
if (ret)
return ret;
faddr = cpu_to_fdt32(resource.start);
paddr = ofnode_translate_address(args.node, &faddr);
...
The both behavior should be aligned and the address translation
must be called in fdt_get_resource() and removed for each caller.
Fixes: a44810123f ("dm: core: Add dev_read_resource() to read device resources")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
In case of failure at efi_get_variable_int("BootOrder"), we should
skip examining boot option variables and return an appropriate error
code which is the one the function returned.
Fixes: CID 331153 Code maintainability issues (UNUSED_VALUE)
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Indicated by Coverity Scan CID 331147
The ESRT was being refreshed in situations where the UpdateCapsule
procedure failed. In that scenario:
1) the ESRT refresh was superfluous.
2) a failed ESRT refresh return code overwrites the UpdateCapsule error
return code.
This commit ensures that the ESRT is only refreshed when the
UpdateCapsule performs successfully.
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Tom Rini <trini@konsulko.com>
CC: Andre Przywara <andre.przywara@arm.com>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Bumping the digest list count, for all supported algorithms, can be
calculated outside of the individual switch statements. So let's do that
for every loop iteration instead and simplify the code a bit.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
To avoid diverging function definitions we need to include efi_loader.h.
Fixes: fe179d7fb5 ("efi_loader: Add size checks to efi_create_indexed_name()")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add 2 configs CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS
to change independently the max number of the regions in lmb
library.
When CONFIG_LMB_USE_MAX_REGIONS=y, move the lmb property arrays to
struct lmb and manage the array size with the element 'max' of struct
lmb_region; their are still allocated in stack.
When CONFIG_LMB_USE_MAX_REGIONS=n, keep the current location in
struct lmb_region to allow compiler optimization.
Increase CONFIG_LMB_RESERVED_REGIONS is useful to avoid lmb errors in
bootm when the number of reserved regions (not adjacent) is reached:
+ 1 region for relocated U-Boot
+ 1 region for initrd
+ 1 region for relocated linux device tree
+ reserved memory regions present in Linux device tree.
The current limit of 8 regions is reached with only 5 reserved regions
in DT.
see Linux kernel commit bf23c51f1f49 ("memblock: Move memblock arrays
to static storage in memblock.c and make their size a variable")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Add a max parameter in lmb_region struct to handle test
in lmb_add_region without using the MAX_LMB_REGIONS
define.
This patch allows to modify these size independently for
memory of reserved regions in the next patches.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Remove the unused field size of struct lmb_region as it is initialized to 0
and never used after in lmb library.
See Linux kernel commit 4734b594c6ca ("memblock: Remove memblock_type.size
and add memblock.memory_size instead")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Variable "final" will have SHA512 digest, but currently
the array size is not sufficient. Let's fix it.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If realloc() fails, we should free the old buffer.
Fixes: c74cd8bd08: ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Remove function invocations using the EFI_CALL macro for those
functions that do not have an EFI_ENTRY call in their definition. Such
functions can use u-boot api's which rely on u-boot global data(gd)
pointer. The Arm and RiscV architectures maintain a separate gd
pointer, one for u-boot, and a separate gd for the efi application.
Calling a function through the EFI_CALL macro changes the gd pointer
to that used for the efi application, with u-boot gd being
unavailable. Any function then trying to dereference u-boot's gd will
result in an abort.
Fix this issue by removing the EFI_CALL macro for all of such
functions which do not begin by an EFI_ENTRY function call.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most modern OpenSSL engines have methods overridden at the EVP level rather
than at RSA level, to make these engines work properly with mkimage, the RSA
signing code needs to switch to using EVP_* APIs as much as possible.
Signed-off-by: Donald Chan <hoiho@lab126.com>
[trini: Rebase on top of keyfile changes]
Signed-off-by: Tom Rini <trini@konsulko.com>
Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the ECDSA signing path to use the appropriate one.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Keys can be derived from keydir, and the "key-name-hint" property of
the FIT. They can also be specified ad-literam via 'keyfile'. Update
the RSA signing path to use the appropriate one.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
mkimage supports rsa2048, and rsa4096 signatures. With newer silicon
now supporting hardware-accelerated ECDSA, it makes sense to expand
signing support to elliptic curves.
Implement host-side ECDSA signing and verification with libcrypto.
Device-side implementation of signature verification is beyond the
scope of this patch.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
fdt_add_bignum() is useful for algorithms other than just RSA. To
allow its use for ECDSA, move it to a common file under lib/.
The new file is suffixed with '-libcrypto' because it has a direct
dependency on openssl. This is due to the use of the "BIGNUM *" type.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
rsa-checksum.c sontains the hash_calculate() implementations. Despite
the "rsa-" file prefix, this function is useful for other algorithms.
To prevent confusion, move this file to lib/, and rename it to
hash-checksum.c, to give it a more "generic" feel.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This introduces strlcat, which provides a safer interface than strncat. It
never copies more than its size bytes, including the terminating nul. In
addition, it never reads past dest[size - 1], even if dest is not
nul-terminated.
This also removes the stub for dwc3 now that we have a proper
implementation.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
strlcpy should always return the number of bytes copied. We were
accidentally missing the nul-terminator. We also always used to return a
non-zero value, even if we did not actually copy anything.
Fixes: 23cd138503 ("Integrate USB gadget layer and USB CDC driver layer")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
