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>
