As removal of nds32 has been ack'd for the Linux kernel, remove support
here as well.
Cc: Rick Chen <rick@andestech.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
To quote the author:
The bootflow feature provide a built-in way for U-Boot to automatically
boot an Operating System without custom scripting and other customisation.
This is called 'standard boot' since it provides a standard way for
U-Boot to boot a distro, without scripting.
It introduces the following concepts:
- bootdev - a device which can hold a distro
- bootmeth - a method to scan a bootdev to find bootflows (owned by
U-Boot)
- bootflow - a description of how to boot (owned by the distro)
This series provides an implementation of these, enabled to scan for
bootflows from MMC, USB and Ethernet. It supports the existing distro
boot as well as the EFI loader flow (bootefi/bootmgr). It works
similiarly to the existing script-based approach, but is native to
U-Boot.
With this we can boot on a Raspberry Pi 3 with just one command:
bootflow scan -lb
which means to scan, listing (-l) each bootflow and trying to boot each
one (-b). The final patch shows this.
With a standard way to identify boot devices, booting become easier. It
also should be possible to support U-Boot scripts, for backwards
compatibility only.
...
The design is described in these two documents:
https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharinghttps://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing
At present it is not possible to find out which part of the string is the
number part and which is before it. Add a new variant which provides this
feature, so we can separate the two in the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this has a minor bug in that it reads the byte before the
start of the string, if it is empty. Also it doesn't handle a
non-numeric prefix which is only one character long.
Fix these bugs with a reworked implementation. Add a test for the second
case. The first one is hard to test.
Signed-off-by: Simon Glass <sjg@chromium.org>
Documentation:
* Document image size parameter of bootefi command
UEFI:
* avoid building partition support in SPL/TPL where not required
* improve integration of EFI subsystem and driver model
* restore ability to boot arbitrary blob
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmJka8UACgkQxIHbvCwF
GsQXVw/+OuG4lYgiBZUUOFtu7CZZTrEnMGszRhXmwEzTMNq2NBNRP1lRJFhyyU50
ElS/I7wZwhFtEnsL5H4mf3Ww7BQLELecg/Q7bnDYhPNg4JWUWUSCGOVUkNRs5O1h
3f6HBkdbvDVvITgopqEj1v4sNwSJCr8sFJQPe0o7i9FAb0+dbO/Er3Z6afp9vcsQ
C6iiNq4zTaGm0YUZf1wOCJMngijvkJ+z+McAFCCAwH0zbT7GfNpmGNr8iviYPWJM
tKzkvO73+LhGR6fgRl9XewbV0Mlkd2q54nfZrP+7tTycIrj0G/OUOyPnOUaJk485
keouzcIVSzZGjeQtsZ9Rrw8EounuMJ/pRyGNsoWIyeY98gqJxtVYnrlNm/TvFs6F
vALsqq0LsRkVmM/ut8eleV/U8Q6n6IYL4xtAH0tm4Jf4mrW1zt8IgWQnNOlHqg9J
RjOAF0y38KUAoC7RzGjU+RJcWPoYuKGxEWEdGvIu3qP9blwaZ7UKRxqWilOgbypf
pxbp9YsnT8pqY9cs6mzSZHPjJFSMVocaRzD521kgShS4cxOJHpZHU4wzd5hS4BFr
BIMCSPPyuRmn3E2DDqncEtL4C7OoPV+LLXVyrF2neiWwjMd/4rGAoYnDwjRkD7dP
uSFsNt9N3Mqpjwl/iMI5Kd+mOJ77TWnf9fKrEft4BIXexopzAms=
=a5qc
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-07-rc1-3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-07-rc1-3
Documentation:
* Document image size parameter of bootefi command
UEFI:
* avoid building partition support in SPL/TPL where not required
* improve integration of EFI subsystem and driver model
* restore ability to boot arbitrary blob
In most of all cases, we can avoid using blk_desc which is expected
to be private to udevice(UCLASS_BLK), that is, the data should not
be manipulated outside the device driver unless really needed.
Now efi_disk's internally use dev_read/write() interfaces
if CONFIG_PARTITIONS is enabled.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When we create an efi_disk device with an UEFI application using driver
binding protocol, the 'efi_driver' framework tries to create
a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
calling a PROBE callback, efi_disk_probe().
In this case, however, we don't need to create another "efi_disk" device
as we already have this device instance.
So we should avoid recursively invoke further processing in the callback
function.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This function is expected to be called, in particular from dm's pre_remove
hook, when associated block devices no longer exist.
Add efi_disk_remove() function.
This function removes an efi_disk object for a raw disk device (UCLASS_BLK)
and related objects for its partitions (UCLASS_PARTITION).
So this function is expected to be called through driver model's "remove"
interface every time a raw disk device is to be disconnected.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
When we create an efi_disk device with an UEFI application using driver
binding protocol, the 'efi_driver' framework tries to create
a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
calling a PROBE callback, efi_disk_probe().
In this case, however, we don't need to create another "efi_disk" device
as we already have this device instance.
So we should avoid recursively invoke further processing in the callback
function.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add efi_disk_probe() function.
This function creates an efi_disk object for a raw disk device (UCLASS_BLK)
and additional objects for related partitions (UCLASS_PARTITION).
So this function is expected to be called through driver model's "probe"
interface every time one raw disk device is detected and activated.
We assume that partition devices (UCLASS_PARTITION) have been created
when this function is invoked.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In the next commit, CONFIG_EFI_SETUP_EARLY will become mandated
in order to support dynamic enumeration of efi_disk objects.
This can, however, be problematic particularly in case of file-based
variable storage (efi_variable.c, default).
Non-volatile variables are to be restored from EFI system partition
by efi_init_variables() in efi_init_obj_list(). When efi_init_obj_list()
is called in board_init_r(), we don't know yet what disk devices
we have since none of device probing commands (say, scsi rescan) has not
been executed at that stage.
So in this commit, a preparatory change is made; efi_init_obj_list() is
broken into the two functions;
* efi_init_early(), and
* new efi_init_obj_list()
Only efi_init_early() will be called in board_init_r(), which allows
us to execute any of device probing commands, either though "preboot"
variable or normal command line, before calling efi_init_obj_list() which
is to be invoked at the first execution of an efi-related command
(or at efi_launch_capsules()) as used to be.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Now we can build efi_loader with block device support (CONFIG_BLK) and
without CONFIG_PARTITIONS.
So change Makefile.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In the current implementation, partition table support (either GPT or DOS)
is not mandatory. So CONFIG_PARTITION_UUIDS should not be enabled
(selected) unconditionally.
Fixes: commit 17f8cda505 ("efi_loader: set partition GUID in device path for SIG_TYPE_GUID")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Commit 690af71850 changed this condition
from an explicit
IS_ENABLED(CONFIG_SPL_SEPARATE_BSS)
to
CONFIG_IS_ENABLED(SEPARATE_BSS)
The documentation for CONFIG_IS_ENABLED() in include/linux/kconfig.h
implies that we will get the correct behaviour, but the actual behaviour
differs such that this condition is now always false.
This stopped TPL being able to load the device tree blob at least on the
ROCKPro64 board (RK3399 SoC), since the wrong device tree location was
chosen.
The issues causing this behaviour with CONFIG_IS_ENABLED() are:
1. The documentation implies that CONFIG_SPL_BUILD =>
CONFIG_SPL_<option> is considered before the TPL equivalent.
Actually, the TPL options have higher priority - see definition of
_CONFIG_PREFIX.
2. The documentation implies a fallthrough, eg. if CONFIG_SPL_BUILD is
defined but the CONFIG_SPL_<option> is not, then it will proceed to
check if CONFIG_TPL_BUILD
Actually, if CONFIG_TPL_BUILD is defined, then it stops there
and CONFIG_SPL_BUILD is not considered - see definition of
_CONFIG_PREFIX.
During TPL build, at least for the ROCKPro64, both CONFIG_TPL_BUILD
and CONFIG_SPL_BUILD are defined, but because of the above, only TPL
options are considered. Since there is no CONFIG_TPL_SEPARATE_BSS,
this fails.
Fixes: 690af71850 ("fdt: Correct condition for SEPARATE_BSS")
Signed-off-by: Andrew Abbott <andrew@mirx.dev>
U-Boot CRC-16 implementation uses polynomial x^16 + x^12 + x^5 + 1 which is
not standard CRC-16 algorithm, but it is known as CRC-16-CCITT. Rename file
crc16.c to crc16-ccitt.c to reduce confusion.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
The capsule update code has been modified for getting the image GUID
values from the platform code. With this, each image now has a unique
GUID value. With this change, there is no longer a need for defining
GUIDs for FIT and raw images. Remove these GUID values.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Currently, there are a bunch of boards which enable the UEFI capsule
update feature. The actual update of the firmware images is done
through the dfu framework which uses the dfu_alt_info environment
variable for getting information on the update, like device, partition
number/address etc. The dfu framework allows the variable to be set
through the set_dfu_alt_info function defined by the platform, or if
the function is not defined, it gets the variable from the
environment. Using the value set in the environment is not very
robust, since the variable can be modified from the u-boot command
line and this can cause an incorrect update.
To prevent this from happening, define the set_dfu_alt_info function
when the capsule update feature is enabled. A weak function is defined
which sets the dfu_alt_info environment variable by getting the string
for the variable from the platform.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
The current capsule update code compares the image GUID value in the
capsule header with the image GUID value obtained from the
GetImageInfo function of the Firmware Management Protocol(FMP). This
comparison is done to ascertain if the FMP's SetImage function can be
called for the update. Make this checking more robust by comparing the
image_index value passed through the capsule with that returned by the
FMP's GetImageInfo function. This protects against the scenario of the
firmware being updated in a wrong partition/location on the storage
device if an incorrect value has been passed through the capsule,
since the image_index is used to determine the location of the update
on the storage device.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Currently, the image descriptor array that has been passed to the
GetImageInfo function of the Firmware Management Protocol(FMP) gets
populated through the data stored with the dfu framework. The
dfu data is not restricted to contain information only of the images
updatable through the capsule update mechanism, but it also contains
information on other images. The image descriptor array is also parsed
by the ESRT generation code, and thus the ESRT table contains entries
for other images that are not being handled by the FMP for the capsule
updates. Fix this by populating the image descriptor array from the
structure initialised in the board file.
The other issue fixed is assignment of a separate GUID for all images
in the image descriptor array. The UEFI specification mandates that
all entries in the ESRT table should have a unique GUID value as part
of the FwClass member of the EFI_SYSTEM_RESOURCE_ENTRY. Currently, all
images are assigned a single GUID value, either an FIT GUID or a raw
image GUID. This is fixed by obtaining the GUID values from the
efi_fw_images array defined per platform.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Set digest_size SHA384 and SHA512 algorithms in pkcs7 and x509,
(not set by ported linux code, but needed by __UBOOT__ part).
EFI_CAPSULE_AUTHENTICATE doesn't select these algos but required for
correctness if certificates contain sha384WithRSAEncryption or
sha512WithRSAEncryption OIDs.
Signed-off-by: Dhananjay Phadke <dphadke@linux.microsoft.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Modify function to support any salt length instead of max
length only. Function now detects salt length by parsing
the content of db buffer. Note that it works with (but is
not limited to) zero-length, digest-length and max-length
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Prior to introduction of modifications in rsassa_pss functions
related to padding verification, doing a pass to reduce memory
consumption of function by replacing memory copies of parts of
const buffer by pointers to the original buffer (masked_db and
h are subparts of msg buffer which is declared const, salt is a
subpart of db which is a working buffer, unmodified after being
filled). New pointers scope is limited to the function where
they are declared (not returned to caller by any mean), zeroing
risk of memory fault related to the change.
Signed-off-by: SESA644425 <gioja.hermann@non.se.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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>
Use sysreset_walk_halt() directly from reset-after-capsule-on-disk
feature to reboot (cold reset) machine instead of using reset command
interface, since this is not a command.
Note that this will make CONFIG_EFI_CAPSULE_ON_DISK depending on
the CONFIG_SYSRESET.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Make efi_load_capsule_drivers() available even if EFI_CAPSULE_ON_DISK
is disabled because the caller (efi_init_obj_list()) expects it only
relays on EFI_HAVE_CAPSULE_SUPPORT.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Since be66b89da3 ("efi_loader: configuration of variables store")
the choice of EFI_VARIABLE_FILE_STORE or EFI_MM_COMM_TEE
is mutually-exclusive, however efi_var_to_file also allows
for "neither". Provide an additional Kconfig option.
Signed-off-by: Tom Saeger <tom.saeger@oracle.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We don't use an appended tree for sandbox and the required symbols are
not present. Add a condition to avoid a build error.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the buffer is empty and not allocated, then abuf_realloc() tries to
copy invalid data. This happens because an incorrect change to use
memdup() was added after the original code was written.
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit adds the option SPL_RSA_VERIFY_WITH_PKEY.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
This commit adds the options:
- SPL_ASYMMETRIC_KEY_TYPE
- SPL_ASYMMETRIC_PUBLIC_KEY_SUBTYPE
- SPL_RSA_PUBLIC_KEY_PARSER
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
This commit adds the options:
- SPL_ASN1_DECODER
- SPL_OID_REGISTRY
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Enhance the help for the config OID_REGISTRY.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Enhance the help for configs ASN1_COMPILER
and ASN1_decoder.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
It seems a copy'n'paste typo when tool had been introduced.
It has never had the 'exit' suffix in the file name. Hence,
the custom CFLAGS never been applied and, for example, BFD
linker complains:
LD lib/efi_loader/initrddump_efi.so
ld.bfd: lib/efi_loader/initrddump.o: warning: relocation in read-only section `.text.efi_main'
ld.bfd: warning: creating DT_TEXTREL in a shared object
Remove wrong 'exit' suffix from the custom CFLAGS variable.
Fixes: 65ab48d69d ("efi_selftest: provide initrddump test tool")
Fixes: 9c045a49a9 ("efi_loader: move dtbdump.c, initrddump.c to lib/efi_loader")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Drop the Kconfigs which are not used and all references to them. In
particular, this drops CONFIG_VIDEO to avoid confusion and allow us to
eventually rename CONFIG_DM_VIDEO to CONFIG_VIDEO.
Also drop the prototype for video_get_info_str() which is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
Up to now the initrddump.efi application has drained the input after
showing the prompt. This works for humans but leads to problems when
automating testing. If the input is drained, this should be done before
showing the prompt.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
initrddump.efi uses colored output and clear the screen. This is not
helpful for integration into Python tests. Allow specifying 'nocolor' in
the load option data to suppress color output and clearing the screen.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The tools dtbdump.efi and initrddump.efi are useful for Python testing even
if CONFIG_EFI_SELFTEST=n.
Don't clear the screen as it is incompatible with Python testing.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The block IO protocol may be installed on any handle. We should make
no assumption about the structure the handle points to.
efi_disk_is_system_part() makes an illegal widening cast from a handle
to a struct efi_disk_obj. Remove the function.
Fixes: Fixes: 41fd506842 ("efi_loader: disk: add efi_disk_is_system_part()")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The boot manager must support loading from boot options using a short-form
device-path, e.g. one where the first element is a hard drive media path.
See '3.1.2 Load Options Processing' in UEFI specification version 2.9.
Fixes: 0e074d1239 ("efi_loader: carve out efi_load_image_from_file()")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Let function efi_dp_find_obj() additionally check if a given protocol is
installed on the handle relating to the device-path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_dp_find_obj() should not return any handle with a partially matching
device path but the handle with the maximum matching device path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Starting UEFI Spec 2.8 we must fill in the variable attributes when
GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL.
This code was written with 2.7 in mind so let's move the code around a
bit and fill in the attributes EFI_BUFFER_TOO_SMALL is returned
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Update the LZ4 compression module based on LZ4 v1.8.3 in order to
use the newest LZ4_decompress_safe_partial() which can now decode
exactly the nb of bytes requested.
Signed-off-by: Huang Jianan <jnhuang95@gmail.com>
InstallProtocolInterface() is called with a pointer to the protocol GUID.
There is not guarantee that the memory used by the caller for the protocol
GUID stays allocated. To play it safe the GUID should be copied to U-Boot's
internal structures.
Reported-by: Joerie de Gram <j.de.gram@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since OpenSSL 1.1.0, EVP_MD_CTX_create() is EVP_MD_CTX_new()
EVP_MD_CTX_destroy() is EVP_MD_CTX_free()
EVP_MD_CTX_init() is EVP_MD_CTX_reset()
As there's no need to reset a newly created EVP_MD_CTX, moreover
EVP_DigestSignInit() does the reset, thus call to EVP_MD_CTX_init()
can be dropped.
As there's no need to reset an EVP_MD_CTX before it's destroyed,
as it will be reset by EVP_MD_CTX_free(), call to EVP_MD_CTX_reset()
is not needed and can be dropped.
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.
1) The EFI Image may reset or disable the watchdog timer as needed.
2) If control is returned to the firmware's boot manager,
the watchdog timer must be disabled.
3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
the watchdog timer is disabled.
1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.
In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add a cold reset soon after processing capsule update on disk.
This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;
In all cases that a capsule is identified for processing the system is
restarted after capsule processing is completed.
This also reports the result of each capsule update so that the user can
notice that the capsule update has been succeeded or not from console log.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Since the efi_update_capsule() represents the UpdateCapsule() runtime
service, it has to handle the capsule flags and update ESRT. However
the capsule-on-disk doesn't need to care about such things.
Thus, the capsule-on-disk should use the efi_capsule_update_firmware()
directly instead of calling efi_update_capsule().
This means the roles of the efi_update_capsule() and capsule-on-disk
are different. We have to keep the efi_update_capsule() for providing
runtime service API at boot time.
Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The general rule of accepting or rejecting an image is
1. Is the sha256 of the image in dbx
2. Is the image signed with a certificate that's found in db and
not in dbx
3. The image carries a cert which is signed by a cert in db (and
not in dbx) and the image can be verified against the former
4. Is the sha256 of the image in db
For example SHIM is signed by "CN=Microsoft Windows UEFI Driver Publisher",
which is issued by "CN=Microsoft Corporation UEFI CA 2011", which in it's
turn is issued by "CN=Microsoft Corporation Third Party Marketplace Root".
The latter is a self-signed CA certificate and with our current implementation
allows shim to execute if we insert it in db.
However it's the CA cert in the middle of the chain which usually ends up
in the system's db. pkcs7_verify_one() might or might not return the root
certificate for a given chain. But when verifying executables in UEFI, the
trust anchor can be in the middle of the chain, as long as that certificate
is present in db. Currently we only allow this check on self-signed
certificates, so let's remove that check and allow all certs to try a
match an entry in db.
Open questions:
- Does this break any aspect of variable authentication since
efi_signature_verify() is used on those as well?
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The EFI spec allows for images to carry multiple signatures. Currently
we don't adhere to the verification process for such images.
The spec says:
"Multiple signatures are allowed to exist in the binary's certificate
table (as per PE/COFF Section "Attribute Certificate Table"). Only one
hash or signature is required to be present in db in order to pass
validation, so long as neither the SHA-256 hash of the binary nor any
present signature is reflected in dbx."
With our current implementation signing the image with two certificates
and inserting both of them in db and one of them dbx doesn't always reject
the image. The rejection depends on the order that the image was signed
and the order the certificates are read (and checked) in db.
While at it move the sha256 hash verification outside the signature
checking loop, since it only needs to run once per image and get simplify
the logic for authenticating an unsigned imahe using sha256 hashes.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
MCFG tables are used on multiple arches. Move to common ACPI lib.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Moritz Fischer <moritzf@google.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use sizeof(*mcfg) instead of sizeof(*header)
Signed-off-by: Simon Glass <sjg@chromium.org>
When we have the block descriptor we can simply access the device. Drop
the unnecessary function call.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Use this function rather than following the pointers, since it is there
for this purpose.
Add the uclass name to the debug call at the end of dp_fill() since it is
quite useful.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When loading an EFI binary via the UART we assign a UART device path to it.
But we lack a handle with that device path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The UEFI specification concerning Uart() device path nodes has been
clarified:
Parity and stop bits can either both use keywords or both use
numbers but numbers and keywords should not be mixed.
Let's go for keywords as this is what EDK II does. For illegal
values fall back to numbers.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The printing of a file path node must properly handle:
* odd length of the device path node
* UTF-16 character only partially contained in device path node
* buffer overflow due to very long file path
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The test for the RISCV_EFI_BOOT_PROTOCOL retrieves the boot hart id via the
protocol and compares it to the value of the boot hart id in the device
tree. The boot hart id is already retrieved from the device tree in the FDT
test.
Merge the two tests to avoid code duplication.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present we use wide characters for Unicode but this is not necessary.
Change the code to use the 'u' literal instead. This helps to fix build
warnings for sandbox on the Raspberry Pi.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
At present we use wide characters for unicode but this is not necessary.
Change the code to use the 'u' literal instead. This helps to fix build
warnings for sandbox on rpi.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Documentation:
* update Nokia RX-51 documentation and move it to rst
* describe boot switch settings for HiFive Unmatched board
UEFI:
* fix the checking of images hashes and signatures
* provide the RISCV_EFI_BOOT_PROTOCOL
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmH1CY8ACgkQxIHbvCwF
GsTTXA/+L53FjKHiOQLf9+FrNO7AZ7OcL51brl97eRuQ/jVaF4ClPnDrwPv+uj8m
rXJHZr6WLRc7A1bIwTYhoetrir07A4pZSHAiKTQuJS2uVFgX25Lp4y5vPt1jgIwF
BsRyVxF50crNQjDuSDUQF6RHCa5QhvgZ9mZ/WQQ0MjRRysnw6sISvNc9HbZLdbau
FheOHERJknE1HELeAg/5KKRn1lt3ew6/QdEqPCvKuhsNW4y31zYyHXt1bvpK8cq0
6m2fRX87nnaIExAb3WLiID91jyPMmrg3ZUndFJfjcAwjelYa50xxHr/vEgw9S1Pb
xMMZSKTmEFoVdX7umW9uw/p0tWygGOUw8/d9bsZPv7qh1akwoKog2BVl/zRbW+5n
x4zCNXOllh0p2u8rRQRu8BqVNXZpw+Intk5frVPeazwbnvBrZFd7jN3JyHMtbUkv
xXJBgHQgbn3z3+zQf9XEa7VjQ+l92x5n0IRWlRxYYEUkMW6o8XZyhzY5Xn1Q7K2z
kLBx/U7o633D2BPtlt66HmIJa/fH02nD7TmmQy3j0ICQdB2GbHOs2uRF5rATV7v0
LukLrTr7kSebOhyINvabsLl126URsx2YjUs7lhPy6ILWm+QGUs8tqyKdTe0gQ7AZ
vneyV2v3CDmMBF3MhE178/kdoJnwk8q7c7JiCQpLNXA33CJCnxw=
=+edp
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-04-rc1-3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-04-rc1-3
Documentation:
* update Nokia RX-51 documentation and move it to rst
* describe boot switch settings for HiFive Unmatched board
UEFI:
* fix the checking of images hashes and signatures
* provide the RISCV_EFI_BOOT_PROTOCOL
We don't have to recalculate the image hash every time we check against a
new db/dbx entry. So let's add a flag forcing it to run once since we only
support sha256 hashes
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
A mix of signatures and hashes in db doesn't always work as intended.
Currently if the digest algorithm is not explicitly set to sha256 we
stop walking the security database and reject the image.
That's problematic in case we find and try to check a signature before
inspecting the sha256 hash. If the image is unsigned we will reject it
even if the digest matches.
Since we no longer reject the image on unknown algorithms add an explicit
check and reject the image if any other hash algorithm apart from sha256
is detected on dbx.
Suggested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
On RISC-V a new UEFI protocol has been introduced. Support printing
its GUID using %pUs.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This adds support for new RISCV_EFI_BOOT_PROTOCOL to
communicate the boot hart ID to bootloader/kernel on RISC-V
UEFI platforms.
The specification of the protocol is hosted at:
https://github.com/riscv-non-isa/riscv-uefi
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add to support rsa 3072 bits algorithm in tools
for image sign at host side and adds rsa 3072 bits
verification in the image binary.
Add test case in vboot for sha384 with rsa3072 algorithm testing.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
binman support for bintools (binary tools)
minor tools improvements in preparation for FDT signing
various minor fixes and improvements
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAmHyEeYRHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreYYlgf8C7tQVklXz9ZHhxVrFaPHWwgmBzEZJSrc
7SWhDX9yBrAYBUk8Q4OMnJz6nXW8Rz5Td9GfBNWcJag1HjJqno4BxkqwGk2tshgj
GIY0D1cGfKJzB4E6/rK/ETwmX4KVUyEf7S2IdJ0oydkn9t7OwDkUX5WtGXo70E7q
ZJGYlX5NQCVBRAF9NYDuyVFljrPzAiyT58VCtXY3q63C7PmRYvag8r56ug+8lkk3
9EbOTcwETqq9SbT1vucyBxwbUmoKhb2BF32jEcIhozowIM3GNsSpkdzQCUnylqfa
LYI/p0oVTKLfFRBRvQjLgdB/OQP8MLkby8A++Db2OW49mBXhn/5JWA==
=PdpE
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-26jan22' of https://source.denx.de/u-boot/custodians/u-boot-dm
acpi refactoring to allow non-x86 use
binman support for bintools (binary tools)
minor tools improvements in preparation for FDT signing
various minor fixes and improvements
It is currenly only used from usbtty driver but make it properly
selectable via Kconfig symbol, for future usage.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Add some more debugging to make it easier to see what is being tried and
what fails. Fix a few comment styles while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this list is used to collect items within the DSDT and SSDT
tables. It is useful for it to collect the whole tables as well, so there
is a list of what was created and which write created each one.
Refactor the code accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this over to use a writer file, moving the code from the x86
implementation.
There is no need to store a separate variable since we can simply access
the ACPI context.
With this, the original monolithic x86 function for writing ACPI tables
is gone.
Note that QEMU has its own implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this function to the newer style, so we can avoid passing and
returning an address through this function.
Also move this function out of the x86 code so it can be used by other
archs.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Disable this table for sandbox since we don't actually compile real ASL
code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move this table over to use a writer function, moving the code from the
x86 implementation.
Add a pointer to the DSDT in struct acpi_ctx so we can reference it later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the base tables at the start of the area,
moving this code from the x86 implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the new ACPI writer to write the ACPI tables. At present this is all
done in one monolithic function. Future work will split this out.
Unfortunately the QFW write_acpi_tables() function conflicts with the
'writer' version, so disable that for sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present acpi_setup_base_tables() both sets up the ACPI context and
writes out the base tables.
We want to use an ACPI writer to write the base tables, so split this
function into two, with acpi_setup_ctx() doing the context set, and
acpi_setup_base_tables() just doing the base tables.
Disable the writer's write_acpi_tables() function for now, to avoid
build errors. It is enabled in a following patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we call lots of functions to generate the required ACPI tables.
It would be better to standardise these functions and allow them to be
automatically collected and used when needed.
Add a linker list to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than keying everything off ACPIGEN, use the main
GENERATE_ACPI_TABLE option to determine whether the core ACPI code
is included. Make sure these option are not enabled in SPL/TPL since we
never generate tables there.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current EFI implementation confuses pointers and addresses. Normally
we can get away with this but in the case of sandbox it causes failures.
Despite the fact that efi_allocate_pages() returns a u64, it is actually
a pointer, not an address. Add special handling to avoid a crash when
running 'bootefi hello'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow this to be used on any arch. Also convert to using macros so that
we can check the CONFIG option in C code.
Signed-off-by: Simon Glass <sjg@chromium.org>
These have sadly found their way to ARM now. Allow any arch to support
generating ACPI tables.
Disable this for the tools build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Documentation:
* describe printf() format codes
UEFI
* enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048
General
* simplify printing short texts for GUIDs
* provide a unit test for printing GUIDs
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmHoLnQACgkQxIHbvCwF
GsQ25Q/9G5REcgmo9Hjv+2ri3VJJueIGRL1QeXDl84TxUYgYAtHj7zo/YaeacHKB
RVBsQafU6vIuAq5YRJFKCSWCxjPJVUH9QO5QQz6RE14KoBh6OYUQP2wSf/+p6/sb
47wfVtyAUEpCEz60eDj5EWrSPpH78BNW7MmKoTZWSgE1APaBTAHw/Uo6tnb52Qsv
vQ73Q9R4s0hpsylVtmwIZ0udDcaJg3SQf/4glhnHxaUW/oMoRd0DU7Dnbbg2oxfd
Y03J0zarqAdIjzNvADnUz6Ei2+H1TrzRe9tzhuXRuseZdANrUnzDIe6bdz+RCmkl
sdBCmBDPoChosiAcaX9FkajaAi5XYpZ5Sitdpp9A8ZdVc0Lzr1XLbfLksJRM7WwM
jSP/JDAGYzJqL86C4hrx46aERUuXgywf/vSM7UoG5OxbtMa/AqbHuXMOnd4jXGYD
48fLlyMWlZ7+Kd4v3x9QlwSmM0LLsokn93JEWrJhJqFPzdHYUQifU2vlZmrJHWyS
BjzCJxu+rCmXBO6wlcAvsF9V/kx5IO3CKIGn24UUt/wjSBu4VDO5oSzVseJxPBIQ
vBV9qZfwKCk9U/F1VN43xvIKvcO+oK+pEE9FB5trffYGmHfSEmBwOq3LuHlyMpeJ
L+TrJUsZstFtx0ZBmVB3YuERusb2z+x1osnifGJvUHCLqjCgvl0=
=GoR6
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-04-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-04-rc1-2
Documentation:
* describe printf() format codes
UEFI
* enable more algorithms for UEFI image verification, e.g. SHA256-RSA2048
General
* simplify printing short texts for GUIDs
* provide a unit test for printing GUIDs
Right now the code explicitly limits us to sha1,256 hashes with RSA2048
encryption. But the limitation is artificial since U-Boot supports
a wider range of algorithms.
The internal image_get_[checksum|crypto]_algo() functions expect an
argument in the format of <checksum>,<crypto>. So let's remove the size
checking and create the needed string on the fly in order to support
more hash/signing combinations.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The ESRT test may try to print a GUID if an error occurs.
Implement the %pU print code.
Correct the ESRT test to use %pU instead of %pUl to avoid the output
of character 'l'.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For printing GUIDs with macro EFI_ENTRY use %pUs instead of %pUl to provide
readable debug output.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In different places text representations are used for GUIDs, e.g.
* command efidebug
* command part list for GPT partitions
To allow reducing code duplication introduce a new printf code %pUs.
It will call uuid_guid_get_str() to get a text representation. If none is
found it will fallback to %pUl and print a hexadecimal representation.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently uuid_guid_get_str() is only built if
CONFIG_PARTITION_TYPE_GUID=y.
To make it usable for other GUIDs compile it if CONFIG_LIB_UUID=y.
The linker will take care of removing it if it is unused.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The code is cross-ported from BLAKE2 reference implementation
(https://github.com/BLAKE2/BLAKE2).
With minimal change to remove unused macros/features.
Currently there is only one user inside U-boot (btrfs), and since it
only utilize BLAKE2B, all other favors are all removed.
Signed-off-by: Qu Wenruo <wqu@suse.com>
[trini: Rename ROUND to R to avoid clash with <linux/bitops.h>
Signed-off-by: Tom Rini <trini@konsulko.com>
Documentation:
* Fix building HTML documentation of readthedocs.io
* Add ARM Juno board documentation
* Build requirements for Alpine Linux
* Include DM headers in API documentation
UEFI:
* Fix section alignment of EFI binaries
* Fix header length of RISC-V EFI binaries allowing to run them on EDK II
* Remove kaslr-seed from device tree if the EFI_RNG_PROTOCOL is provided
Other:
* Let 'part list' show all 128 GPT partitions
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmHiqKYACgkQxIHbvCwF
GsTrMA//XQRIS9f8pD3/FsSfVfmtxkCLG9axEe/lRQp7l7109v+m832CJV5Em7pX
GtRGOSUdj930v1q9fZ/nUx9/IJjf/lnB0eEcMcVai2NVgyuRohGAzX9JWsVLbdOE
MicDX7D/VZ+86lPxLRJbq61jMj7Dnj+atonJQ3Bc1eBLutUaBOr6aenA99TyLavU
+guuQmQLpJz6VbyZIYxr7/CZVaVkXS0jmcfEoDHD8BrsBe3pZvNuUC4D9KIFWnLo
pQYYNuIWiVCPGE/iMbUZGjJfgHnD3qW1DWOfmeWPTysALnTSxx0m8FJrOqlxZk6R
HkEhcr/RkI2JT89C+07qsXkfvJ7YBg3r6bSNtng4i8VwSm384ffF9Y+cfoBv1285
7wo+Vbh6LuOlp0OAo3bjAuhW7gpnUkkGoc4sXv7wr560mGOtJAPrp0T1ku17ZANd
GP0T4TgvL15PAFbK+Yg6NxF+l26Lb5EkvC5bGFlM/5ceafD/B7qA2m8KG9+cR2/t
UFAyI0FB3yWp1TLfdCRXR4YEHDl3nWjs8GuwdwTPFXLWFPkf73DX/r+ZAnZAY+M+
FTGJuMZUp71aiqeAs7CHw4ePZMQCt0Hjs9kYbAMekoUncpMCFXwXmp1KxLkHBM+X
+i6WPflTL/sOSO+3M8fcUeZI7IWerOHZqCu/RTb9W0n3Ee+odBc=
=NZ+6
-----END PGP SIGNATURE-----
Merge tag 'efi-2022-04-rc1' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2022-04-rc1
Documentation:
* Fix building HTML documentation of readthedocs.io
* Add ARM Juno board documentation
* Build requirements for Alpine Linux
* Include DM headers in API documentation
UEFI:
* Fix section alignment of EFI binaries
* Fix header length of RISC-V EFI binaries allowing to run them on EDK II
* Remove kaslr-seed from device tree if the EFI_RNG_PROTOCOL is provided
Other:
* Let 'part list' show all 128 GPT partitions
At present the 'efi' command only works in the EFI payload. Update it to
work in the app too, so the memory map can be examined.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present this code is inline in the app and stub. But they do the same
thing. The difference is that the stub does it immediately and the app
doesn't want to do it until the end (when it boots a kernel) or not at
all, if returning to UEFI.
Move it into a function so it can be called as needed.
Add a comment showing how to store the memory map so that it can be
accessed within the app if needed, for debugging purposes only. The map
can change without notice.
Signed-off-by: Simon Glass <sjg@chromium.org>
If variable dfu_alt_info is not defined duplicate messages are displayed.
=> efidebug boot dump
Scanning disk mmc2.blk...
Scanning disk mmc1.blk...
Scanning disk mmc0.blk...
Found 3 disks
No EFI system partition
"dfu_alt_info" env variable not defined!
Probably dfu_alt_info not defined
"dfu_alt_info" env variable not defined!
Probably dfu_alt_info not defined
Remove the 'Probably dfu_alt_info not defined' message.
Instead write a warning if the variable contains no entities.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
node. That would be problematic in case we want to measure the DTB we
install in the configuration table, since it would change across reboots.
The Linux kernel EFI-stub completely ignores it and only relies on
EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
of the physical placement of the kernel). In fact it (blindly) overwrites
the existing seed if the protocol is installed. However it still uses it
for randomizing it's virtual placement.
So let's get rid of it in the presence of the RNG protocol.
It's worth noting that TPMs also provide an RNG. So if we tweak our
EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
is present the 'kaslr-seed' property will always be removed, allowing
us to reliably measure our DTB.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
CONFIG_PHANDLE_CHECK_SEQ is outside of the menu 'Library routines'
thus it's invisible in menuconfig and cannot be selected.
Fix this by moving the 'endmenu' after the PHANDLE_CHECK_SEQ definition
Fixes: c589132a1d ("fdt: Use phandle to distinguish DT nodes with same name")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
CHUNK_TYPE_RAW buffer is not aligned, and flash sparse images by
fastboot will report "Misaligned operation" if DCACHE is enabled.
Flashing Sparse Image
CACHE: Misaligned operation at range [84000028, 84001028]
CACHE: Misaligned operation at range [84001034, 84002034]
CACHE: Misaligned operation at range [8401104c, 8401304c]
Fix it
Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
Reviewed-by: Sean Anderson <sean.anderson@seco.com>
The return type of EVP_PKEY_get0_RSA() is const struct rsa_st *.
Our code drops the const qualifier leading to
In file included from tools/lib/rsa/rsa-sign.c:1:
./tools/../lib/rsa/rsa-sign.c: In function ‘rsa_add_verify_data’:
./tools/../lib/rsa/rsa-sign.c:631:13: warning:
assignment discards ‘const’ qualifier from pointer target type
[-Wdiscarded-qualifiers]
631 | rsa = EVP_PKEY_get0_RSA(pkey);
| ^
Add a type conversion.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
- meson64_android: add board specific env settings, in order to support VIM3/L for android
- add changes to support VIM3/L android boot by using meson64_android.h config
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPVPGJshWBf4d9CyLd9zb2sjISdEFAmHYV8MACgkQd9zb2sjI
SdELkA/+LjyjJB1KI6/KLLg43zyFeeZX/SjQd5BUIx6EfaCgyTkuq2lzQnErGmbi
HoyMoNLpBxLIL27/5TXPzmKYAeOfKPxA/sXTTtx/l7PG8ncSZIoU0+utqjycdUsK
tSi7EdFzk7/kDDRkqqA7q9nxsPn/7GQNh/ZC9zstMXKaTO/TEb/sZWCMcvQ0MNoB
ynZKOCg5t60UkIYIRwZwC/OS/ssn86dovv/Aa/8D6qpL2AbS5DoCXHuAr8Dnz7fJ
q4rV7oLh7a+WHe/qC7R6ylYFIVVqY5JaIgbLDwuvk1z9o7txchMMQnGgllZ35sN9
LECD2iSDGjhPaHuGCvQwl3TWtIpvtdcP4sQTyJhsXNPxCG6HHvRz7xY4erUohR1I
LIddwCCHeCrBiaamXNbCzph2+JhfPSQ5ETCL9M6iBMxNUPunlCxjfjDzlT/pg11p
EO9PIPjRMR9QhxKtd3gZpyAqPuMBEmIwhDtHI6dL3DNOOsF44ObE4swnzS6qXIDn
jRZzFCC2f/Vyg11YnzFtV3A5eWwJahGDWAGAnnlg6Y8GCLlLmDJitcgA/rWSALko
T5fC8L8IFUx2RnHczyitJ/wqJl9FqOAnIaoB3Trpwp8gFQ15dQjbvoXldQnAjSS2
9bns3zOrx79EF4lbHhwNE9UDLm6OjK5vR3h4bGJvyZBmasVsA90=
=dLEg
-----END PGP SIGNATURE-----
Merge tag 'u-boot-amlogic-20220107' of https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
- disable CONFIG_NET_RANDOM_ETHADDR when unnecessary on amlogic based configs
- meson64_android: add board specific env settings, in order to support VIM3/L for android
- add changes to support VIM3/L android boot by using meson64_android.h config
Add a message here so that both paths of memory allocation are reported.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The stub checks for failure with efi_init(). Add this for the app as well.
It is unlikely that anything can be done, but we may as well stop.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
At present each of these has its own static variable and helper functions.
Move them into a shared file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Comment some functions that need more information.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.
EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
This can be expanded later as needed.
We cannot use printf() in the early stub or app since it is not compiled
in
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This is needed to show unicode strings. Enable this code in the app.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently we allow and explicitly check a single shared page with
StandAloneMM. This is dictated by OP-TEE which runs the application.
However there's no way for us dynamically discover the number of pages we
are allowed to use. Since writing big EFI signature list variable
requires more than a page, OP-TEE has bumped the number of shared pages to
four.
Let's remove our explicit check and allow the request to reach OP-TEE even
if it's bigger than what it supports. There's no need to sanitize the
number of pages internally. OP-TEE will fail if we try to write more
than it's allowed. The error will just trigger later on, during the
StMM access.
While at it add an error message to help users figure out what failed.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Signed-off-by: Ilias Apalodimas <apalos@gmail.com>
In order to finish moving this symbol to Kconfig for all platforms, we
need to do a few more things. First, for all platforms that define this
to a function, introduce CONFIG_DYNAMIC_SYS_CLK_FREQ, similar to
CONFIG_DYNAMIC_DDR_CLK_FREQ and populate clock_legacy.h. This entails
also switching all users from CONFIG_SYS_CLK_FREQ to get_board_sys_clk()
and updating a few preprocessor tests.
With that done, all platforms that define a value here can be converted
to Kconfig, and a fall-back of zero is sufficiently safe to use (and
what is used today in cases where code may or may not have this
available). Make sure that code which calls this function includes
<clock_legacy.h> to get the prototype.
Signed-off-by: Tom Rini <trini@konsulko.com>
Our Gitlab CI buildsystem is set up to treat warnings as errors.
With OpenSSL 3.0 a lot of deprecation warnings occur.
With the patch compatibility with OpenSSL 1.1.1 is declared.
In the long run we should upgrade our code to use the current API.
A -Wdiscarded-qualifiers warning is muted by casting.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently we allow and explicitly check a single shared page with
StandAloneMM. This is dictated by OP-TEE which runs the application.
However there's no way for us dynamically discover the number of pages we
are allowed to use. Since writing big EFI signature list variable
requires more than a page, OP-TEE has bumped the number of shared pages to
four.
Let's remove our explicit check and allow the request to reach OP-TEE even
if it's bigger than what it supports. There's no need to sanitize the
number of pages internally. OP-TEE will fail if we try to write more
than it's allowed. The error will just trigger later on, during the
StMM access.
While at it add an error message to help users figure out what failed.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Signed-off-by: Ilias Apalodimas <apalos@gmail.com>
When U-Boot is started from another firmware program, not just a prior
phase of U-Boot, special behaviour is typically used. In particular, the
device tree may come from that prior stage.
At present this is sort-of indicated by OF_BOARD, although the
correlation is not 1:1, since that option simply means that the board has
a custom mechanism for obtaining the device tree. For example, sandbox
defines OF_BOARD. Also the board_fdt_blob_setup() function can in fact
make use of the devicetree in U-Boot if it wishes, as used by
dragonboard410c until very recently.
Add an explicit Kconfig for this situation. Update the OF_BOARD option to
more-accurately reflect what it is doing, e.g. for sandbox.
Drop the docs in the README as it is out of date.
Signed-off-by: Simon Glass <sjg@chromium.org>
It can be confusing to figure out where the devicetree came from. It seems
important enough to warrant a message during boot. Add information about
the number of devices and uclasses too since it is helpful to have some
idea what is going on with driver model.
Report the devicetree source in bdinfo too.
This looks something like this, with > marking the new line.
U-Boot 2021.10-00190 (Oct 30 2021 - 09:01:29 -0600)
DRAM: 128 MiB
> Core: 42 devices, 11 uclasses, devicetree: passage
Flash: 64 MiB
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this override function is called even when OF_BOARD is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
A follower patch adds warnings for this scenario, but for now we don't
have a Kconfig that definitively tells us that OF_BOARD should be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function should only be called when OF_CONTROL is enabled. It
fails in fdtdec_prepare_fdt() anyway, since gd->fdt_blob stays as NULL
if OF_CONTROL is not enabled.
Drop this useless check.
Signed-off-by: Simon Glass <sjg@chromium.org>
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
These names are better used for access to devices provided by an EFI
layer. Use EFI_LOADER instead here, since these are only available in
U-Boot's EFI_LOADER layer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
When the TCG2 protocol is installed in efi_tcg2_register(),
TPM2 device must be present.
tcg2_measure_pe_image() expects that TCP2 protocol is installed
and TPM device is available. If TCG2 Protocol is installed but
TPM device is not found, tcg2_measure_pe_image() returns
EFI_SECURITY_VIOLATION and efi_load_image() ends with failure.
The same error handling is applied to
efi_tcg2_measure_efi_app_invocation().
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There are functions that calls tcg2_agile_log_append() outside
of the TCG protocol invocation (e.g tcg2_measure_pe_image).
These functions must to check that TCG2 protocol is installed.
If not, measurement shall be skipped.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This commit modify efi_tcg2_register() to return the
appropriate error.
With this fix, sandbox will not boot because efi_tcg2_register()
fails due to some missing feature in GetCapabilities.
So disable sandbox if EFI_TCG2_PROTOCOL is enabled.
UEFI secure boot variable measurement is not directly related
to TCG2 protocol installation, tcg2_measure_secure_boot_variable()
is moved to the separate function.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Firmwares before U-Boot may be capable of doing tpm measurements
and passing them to U-Boot in the form of eventlog. However there
may be scenarios where the firmwares don't have TPM driver and
are not capable of extending the measurements in the PCRs.
Based on TCG spec, if previous firnware has extended PCR's, PCR0
would not be 0. So, read the PCR0 to determine if the PCR's need
to be extended as eventlog is parsed or not.
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The current tpm2_pcr_read is hardcoded using SHA256. Make the
actual command to TPM configurable to use wider range of algorithms.
The current command line is kept as is i.e limited to SHA-256 only.
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Platforms may have support to measure their initial firmware components
and pass the event log to u-boot. The event log address can be passed
in property tpm_event_log_addr and tpm_event_log_size of the tpm node.
Platforms may choose their own specific mechanism to do so. A weak
function is added to check if even log has been passed to u-boot
from earlier firmware components. If available, the eventlog is parsed
to check for its correctness and further event logs are appended to the
passed log.
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
UEFI code is always little-endian. Remove a superfluous test.
Remove a superfluous type conversion.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If we call efi_clear_os_indications() before initializing the memory store
for UEFI variables a NULL pointer dereference occurs.
The error was observed on the sandbox with:
usb start
host bind 0 sandbox.img
load host 0:1 $kernel_addr_r helloworld.efi
bootefi $kernel_addr_r
Here efi_resister_disk() failed due to an error in the BTRFS implementation.
Move the logic to clear EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED
to the rest of the capsule code.
If CONFIG_EFI_IGNORE_OSINDICATIONS=y, we should still clear the flag.
If OsIndications does not exist, we should not create it as it is owned by
the operating system.
Fixes: 149108a3eb ("efi_loader: clear OsIndications")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Our algorithm for creating USB device paths may lead to duplicate device
paths which result in efi_disk_register() failing. Instead we should just
skip devices that cannot be registered as EFI block devices.
Fix a memory leak in efi_disk_add_dev() caused by the duplicate device
path.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If we look at the path that bootm/booti take when preparing to boot the
OS, we see that as part of (or prior to calling do_bootm_states,
explicitly) the process, bootm_disable_interrupts() is called prior to
announce_and_cleanup() which is where udc_disconnect() /
board_quiesce_devices() / dm_remove_devices_flags() are called from. In
the EFI path, these are called afterwards. In efi_exit_boot_services()
however we have been calling bootm_disable_interrupts() after the above
functions, as part of ensuring that we disable interrupts as required
by the spec. However, bootm_disable_interrupts() is also where we go
and call usb_stop(). While this has been fine before, on the TI J721E
platform this leads us to an exception. This exception seems likely to
be the case that we're trying to stop devices that we have already
disabled clocks for. The most direct way to handle this particular
problem is to make EFI behave like the do_bootm_states() process and
ensure we call bootm_disable_interrupts() prior to ending up in
usb_stop().
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Simon Glass <sjg@chromium.org>
Suggested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Due to U-Boot's lazy binding mentality the TPM is probed but not properly
initialized. The user can startup the device from the command line
e.g 'tpm2 startup TPM2_SU_CLEAR'. However we can initialize the TPM during
the TCG protocol installation, which is easier to use overall.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
As described in the TCG spec [1] in sections 7.1.1 and 7.1.2 the FinalEvent
table should include events after GetEventLog has been called. This
currently works for us as long as the kernel is the only EFI application
calling that. Specifically we only implement what's described in 7.1.1.
So refactor the code a bit and support EFI application(s) calling
GetEventLog. Events will now be logged in both the EventLog and FinalEvent
table as long as ExitBootServices haven't been invoked.
[1] https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Implement the EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES event group
handling.
Add the definition of EFI_EVENT_GROUP_AFTER_READY_TO_BOOT.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Record capsule update result only if the capsule file is
successfully read, because the capsule GUID is not sure when
the file can not be read or the file is not a capsule.
Without this fix, if user puts a dummy (non-capsule) file
under (ESP)EFI/UpdateCapsule, U-Boot causes a synchronous
abort.
This also fixes use-after-free bug of the 'capsule' variable.
Fixes: c74cd8bd08 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
log_info() is used for the debug level logging statement
which should use log_debug() instead. Convert it to reduce the
log output.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In case U-Boot enters relocation with GD_FLG_SKIP_RELOC, skip the
relocation. The code still has to set up new_gd pointer and new
stack pointer.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
In case U-Boot starts with GD_FLG_SKIP_RELOC, the U-Boot code is
not relocated, however the stack and heap is at the end of DRAM
after relocation. Reserve a LMB area for the non-relocated U-Boot
code so it won't be overwritten.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
This command is not compiled by default and has not been updated alongside
changes to the tpmv1 API, such as passing the TPM udevice to the relevant
functions.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add an xtoa() function, similar to itoa() but for hex instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Tested-by: Artem Lapkin <email2tema@gmail.com>
UEFI specification does not require that BootOrder is defined.
In current implementation, boot variable measurement fails and
returns EFI_NOT_FOUND if BootOrder is not defined.
This commit correcly handles this case, skip the boot variable
measurement if BootOrder is not defined.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit adds the missing EFI_TCG2_PROTOCOL selftest
and Measured Boot selftest in lib/efi_selftest.
This selftest includes PE/COFF image measurement test, some PCR values are
different in each architecture. With that, this commit also adds pre-built
versions of lib/efi_selftest/efi_miniapp_file_image_exit.c for PE/COFF
image measurement test for 32-bit arm, arm64, ia32, x86_64, riscv32 and
riscv64. Prebuilding avoids the problem of reproducible builds.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Make the test 'onrequest'.
Add code comments to the includes with the binaries.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add a function to return this information along with a stub for the
efi_info_get() function, since calling it otherwise hangs U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This variable is already defined by the EFI code. Drop the duplicate
definition when building a 64-bit EFI app.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.
Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.
For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Most EFI implementations use 64-bit but U-Boot only supports running as
a 32-bit app at present. While efi-x86_payload64 does boot from 64-bit
UEFI it immediately changes back to 32-bit before starting U-Boot.
In order to support a 64-bit U-Boot app, update the Kconfig to add an
option for 32/64 bit. Update the prompt for the existing option so it is
clear it relates to the stub. Move both up to just under the choice that
controls them, since this looks better and the menu.
Use CONFIG_EFI_APP in the Makefile instead of CONFIG_TARGET_EFI_APP,
since the latter is specific to a single target and we will have two.
Memory size is set to 32MB for now so that it can run on qemu without
increasing the default memory size. We may need to increase the default
later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This commit adds the EFI_TCG2_PROTOCOL.SubmitCommand
required in the TCG PC Client PFP spec.
SubmitCommand enables to send the raw command to the TPM device.
To implement this api, tpm2_submit_command() is added
into tpm-v2.c.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Calling unaligned/access-ok.h version of put_unaligned_le64()
causes data abort in arm 32-bit QEMU.
The similar issue also occurs in linux kernel,
unaligned/access-ok.h is no longer used in linux kernel[1].
This commit uses the unaligned/be_byteshift.h and
unaligned/le_byteshift.h helper instead of unaligned/access-ok.h.
[1]https://lore.kernel.org/all/20210507220813.365382-8-arnd@kernel.org/
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
As we discussed in ML, currently a device tree is the only place
to store public keys for capsule authentication. So __weak is not
necessary for now.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
OF_HOSTFILE is used on sandbox configs only. Although it's pretty
unique and not causing any confusions, we are better of having simpler
config options for the DTB.
So let's replace that with the existing OF_BOARD. U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client Platform Firmware
Profile Specification.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client Platform Firmware
Profile Specification
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Correct the test on RNG device presence,when ret is equal to 0,
before to call dm_rng_read function.
Without this patch the RNG device is not used when present (when ret == 0)
or a data abort occurs in dm_rng_read when CONFIG_DM_RNG is activated but
the RNG device is not present in device tree (ret != 0 and devp = NULL).
Fixes: 92fdad28cf ("lib: uuid: use RNG device if present")
CC: Matthias Brugger <mbrugger@suse.com>
CC: Torsten Duwe <duwe@suse.de>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit adds a check on the padding in the function rsa_verify_key
to avoid using a NULL pointer.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
TCG PC Client Platform Firmware Profile Specification
requires to measure the SMBIOS table that contains static
configuration information (e.g. Platform Manufacturer
Enterprise Number assigned by IANA, platform model number,
Vendor and Device IDs for each SMBIOS table).
The device- and environment-dependent information such as
serial number is cleared to zero or space character for
the measurement.
Existing smbios_string() function returns pointer to the string
with const qualifier, but exisintg use case is updating version
string and const qualifier must be removed.
This commit removes const qualifier from smbios_string()
return value and reuses to clear the strings for the measurement.
This commit also fixes the following compiler warning:
lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
const struct smbios_header *header = (struct smbios_header *)entry->struct_table_address;
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Simplify efi_sigstore_parse_sigdb() by using existing functions.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
In multiple places we need the default GUID matching a variable name.
The patch provides a library function. For secure boot related variables
like 'PK', 'KEK', 'db' a lookup table is used. For all other variable
names EFI_GLOBAL_VARIABLE is returned.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
UEFI variable names are typically constants and hence should be defined as
const. Unfortunately some of our API functions do not define the parameters
for UEFI variable names as const. This requires unnecessary conversions.
Adjust parameters of several internal functions to tre UEFI variable names
as const.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The commit 47a25e81d3 ("Revert "efi_capsule: Move signature from DTB to
.rodata"") failed to revert the removal of efi_get_public_key_data().
Add back this function and move it under lib/efi_loader so that other
platforms can utilize it. It is now declared as a weak function so that
it can be replaced with a platform-specific implementation.
Fixes: 47a25e81d3 ("Revert "efi_capsule: Move signature from DTB to
.rodata"")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This commit fixes the following compilation warning
of boottime->install_configuration_table() function.
lib/efi_selftest/efi_selftest_tcg2.c:475:46:
warning: passing argument 1 of ‘boottime->install_configuration_table’
discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
ret = boottime->install_configuration_table(&smbios_guid, dmi);
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The 'efidebug boot dump' command should not display the VenMedia() device
path node preceding the device path of the initial ram disk.
By letting efi_dp_from_lo() skip the VenMedia() device path node we can
simplify the coding.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Create the GUID as a global variable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Parameter size is never used in function efi_dp_from_lo(). Remove it.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
