| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The efi_parse_pkcs7_header() function returns NULL on error so the check
for IS_ERR() should be changed to a NULL check.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
While UPDATE_CAPSULE api is not fully implemented, this interface and
capsule-on-disk feature should behave in the same way, especially in
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
Reported-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reported-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Remove an unused implementation of efi_capsule_authenticate().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in
EFI capsule reports. Prior to this change is the hard coded value was
65535 which would exceed available storage for variables. Now the
default value is 15 which should work fine with most systems.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
|
|
Up to now we only compared the first letter of the capsule name to sort
them alphabetically. Properly sort by the Unicode alphabet.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
The FWU Multi Bank Update feature supports updating firmware images
to one of multiple sets(also called banks) of images. The firmware
images are clubbed together in banks, with the system booting images
from the active bank. Information on the images such as which bank
they belong to is stored as part of the metadata structure, which is
stored on the same storage media as the firmware images on a dedicated
partition.
At the time of update, the metadata is read to identify the bank to
which the images need to be flashed(update bank). On a successful
update, the metadata is modified to set the updated bank as active
bank to subsequently boot from.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The CloseProtocol() boot service requires a handle as first argument.
Passing the protocol interface is incorrect.
CloseProtocol() only has an effect if called with a non-zero value for
agent_handle. HandleProtocol() uses an opaque agent_handle when invoking
OpenProtocol() (currently NULL). Therefore HandleProtocol() should be
avoided.
* Replace the LocateHandle() call by efi_search_protocol().
* Remove the CloseProtocol() call.
Fixes: 8d99026f0697 ("efi_loader: capsule: support firmware update")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
A following patch is cleaning up the core EFI code trying to remove
sequences of efi_create_handle, efi_add_protocol.
Although this works fine there's a problem with the latter since it is
usually combined with efi_delete_handle() which blindly removes all
protocols on a handle and deletes the handle. We should try to adhere to
the EFI spec which only deletes a handle if the last instance of a protocol
has been removed. Another problem is that efi_delete_handle() never checks
for opened protocols, but the EFI spec defines that the caller is
responsible for ensuring that there are no references to a protocol
interface that is going to be removed.
So let's fix this by replacing all callsites of
efi_create_handle(), efi_add_protocol() , efi_delete_handle() with
Install/UninstallMultipleProtocol.
In order to do that redefine functions that can be used by the U-Boot
proper internally and add '_ext' variants that will be used from the
EFI API
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
CONFIG_EFI_IGNORE_OSINDICATIONS is enabled
The EFI_IGNORE_OSINDICATIONS config symbol was introduced as a
mechanism to have capsule updates work even on platforms where the
SetVariable runtime service was not supported. The current logic
requires the OsIndications variable to have been set to a 64 bit value
even when the EFI_IGNORE_OSINDICATIONS config is enabled. Return an
error code on not being able to read the variable only when
EFI_IGNORE_OSINDICATIONS is not enabled.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
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>
|
|
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>
|
|
EFI_CAPSULE_ON_DISK=n
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>
|
|
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: 41fd506842c2 ("efi_loader: disk: add efi_disk_is_system_part()")
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 149108a3eb59 ("efi_loader: clear OsIndications")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
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: c74cd8bd08d1 ("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>
|
|
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>
|
|
The commit 47a25e81d35c ("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: 47a25e81d35c ("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 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 ddf67daac39de76d2697d587148f4c2cb768f492.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
If capsule authentication is disabled and yet a capsule file is signed,
its signature must be removed from image data to flush.
Otherwise, the firmware will be corrupted after update.
Fixes: 04be98bd6bcf ("efi: capsule: Add support for uefi capsule
authentication")
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
efi_guid_capsule_root_cert_guid is never used.
Just remove it.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
The capsule signature is now part of our DTB. This is problematic when a
user is allowed to change/fixup that DTB from U-Boots command line since he
can overwrite the signature as well.
So Instead of adding the key on the DTB, embed it in the u-boot binary it
self as part of it's .rodata. This assumes that the U-Boot binary we load
is authenticated by a previous boot stage loader.
Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Tested-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Use %pD to log device-path instead of using efi_dp_str() and
efi_free_pool() locally in find_boot_device().
This is a cleanup patch, no feature update nor fix.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Fix find_boot_device() to set bootdev_root if it finds the
bootdev from BootNext. Currently it sets the bootdev_root only
when it finds bootdev from BootOrder.
Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Accked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
If multiple capsules are applied, the FMP drivers for the individual
capsules can expect the value of CapsuleLast to be accurate. Hence
CapsuleLast must be updated after each capsule.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
efi_set_variable() should be called with EFI_CALL(). Use
efi_set_variable_int() instead.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
* Use log category LOGC_EFI. This allows to remove 'EFI:' prefixes in
messages.
* Rephrase some of the messages.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.
Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.
Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: apalos <ilias.apalodimas@linaro.org>
Reword Kconfig description.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
We only install FMPs if a CapsuleUpdate is requested. Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
When running the efidebug capsule disk-update command, the efi_fmp_raw
protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
This is because the code passes efi_root instead of the handle local var.
=> efidebug capsule disk-update
EFI: Call: efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbaf5988)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbaf5988, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6ee8)
EFI: new handle 00000000fbb37520
EFI: Exit: efi_install_protocol_interface: 0
EFI: 0 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 0
EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbfec648)
EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Entry efi_install_protocol_interface(00000000fbfec648, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6f18)
EFI: handle 00000000fbaf8520
EFI: Exit: efi_install_protocol_interface: 2
EFI: 2 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
EFI: Exit: efi_install_multiple_protocol_interfaces: 2
EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
Command failed, result=1
To fix this issue, pass the handle local var which is set NULL right
before installing efi_fmp_raw as same as the installing efi_fmp_fit.
(In both cases, the local reference to the handle will be just discarded)
Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
If opening a file fails, the file handle pointer is not valid and must not
be dereferenced.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Configuring a system with CONFIG_EFI_CAPSULE_AUTHENTICATE=y but without a
method to retrieve the public key data is a misconfiguration. We should get
a build failure for it. Therefore remove the weak efi_get_public_key_data()
implementation.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
In case of failure at efi_get_variable_int("BootOrder"), we should
skip examining boot option variables and return an appropriate error
code which is the one the function returned.
Fixes: CID 331153 Code maintainability issues (UNUSED_VALUE)
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Indicated by Coverity Scan CID 331147
The ESRT was being refreshed in situations where the UpdateCapsule
procedure failed. In that scenario:
1) the ESRT refresh was superfluous.
2) a failed ESRT refresh return code overwrites the UpdateCapsule error
return code.
This commit ensures that the ESRT is only refreshed when the
UpdateCapsule performs successfully.
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Tom Rini <trini@konsulko.com>
CC: Andre Przywara <andre.przywara@arm.com>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
If realloc() fails, we should free the old buffer.
Fixes: c74cd8bd08d1: ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().
The ESRT is recreated from scratch at the following events:
- successful UpdateCapsule;
- FMP instance install.
The code ensures that every ESRT entry has a unique fw_class value.
Limitations:
- The ESRT is not updated if an FMP instance is uninstalled;
- the fields image_type and flags are in the current implementation left
undefined. Setting these values will require a per-platform function
that returns the image_type/flags as a function of the image fw_class.
CC: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Sughosh Ganu <sughosh.ganu@linaro.org>
CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
CC: Andre Przywara <andre.przywara@arm.com>
CC: Alexander Graf <agraf@csgraf.de>
CC: nd@arm.com
Signed-off-by: Jose Marinho <jose.marinho@arm.com>
Remove two EFI_CALL() indirections.
Move ESRT GUID in efidebug's list of GUIDs.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
This occur when building on Raspberry Pi 400 (32-bit ARM). Fix them.
Examples:
cmd/efidebug.c: In function ‘do_efi_capsule_update’:
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:9: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
cmd/efidebug.c:75:49: warning: cast from pointer to integer of different
size [-Wpointer-to-int-cast]
ret = EFI_CALL(RT->update_capsule(&capsule, 1, (u64)NULL));
^
include/efi_loader.h:104:19: note: in definition of macro ‘EFI_CALL’
typeof(exp) _r = exp; \
^~~
In file included from include/common.h:20,
from lib/efi_loader/efi_capsule.c:9:
lib/efi_loader/efi_capsule.c: In function ‘efi_update_capsule’:
include/efi_loader.h:83:8: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘size_t’
{aka ‘unsigned int’} [-Wformat=]
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~~~~~~~~~~~~~~
include/linux/printk.h:37:21: note: in definition of macro ‘pr_fmt’
#define pr_fmt(fmt) fmt
^~~
include/log.h:229:2: note: in expansion of macro ‘log’
log(LOG_CATEGORY, LOGL_DEBUG, fmt, ##args); \
^~~
include/log.h:249:2: note: in expansion of macro ‘debug_cond’
debug_cond(_DEBUG, fmt, ##args)
^~~~~~~~~~
include/efi_loader.h:83:2: note: in expansion of macro ‘debug’
debug("%sEFI: Entry %s(" format ")\n", __efi_nesting_inc(), \
^~~~~
lib/efi_loader/efi_capsule.c:444:2: note: in expansion of macro ‘EFI_ENTRY’
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
^~~~~~~~~
lib/efi_loader/efi_capsule.c:444:19: note: format string is defined here
EFI_ENTRY("%p, %lu, %llu\n", capsule_header_array, capsule_count,
~~^
%u
Signed-off-by: Simon Glass <sjg@chromium.org>
Replace (uintptr_t)NULL by 0.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
fix get_last_capsule() leads to writes beyond the stack allocated buffer.
This was indicated when enabling the stack protector.
utf16_utf8_strcpy() only stops copying when reaching '\0'. The current
invocation always writes beyond the end of value[].
The output length of utf16_utf8_strcpy() may be longer than the number of
UTF-16 tokens. E.g has "CapsuleКиев" has 11 UTF-16 tokens but 15 UTF-8
tokens. Hence, using utf16_utf8_strcpy() without checking the input may
lead to further writes beyond value[].
The current invocation of strict_strtoul() reads beyond the end of value[].
A non-hexadecimal value after "Capsule" (e.g. "CapsuleZZZZ") must result in
an error. We cat catch this by checking the return value of strict_strtoul().
A value that is too short after "Capsule" (e.g. "Capsule0") must result in
an error. We must check the string length of value[].
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
'.' and '..' are directories. So when looking for capsule files it is
sufficient to check that the attribute EFI_FILE_DIRECTORY is not set. We
don't have to check for these special names.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
CID 316361 says:
> Passing argument "count * 8UL /* sizeof (*files) */" to
> function "dlmalloc" and then casting the return value to "u16 **" is
> suspicious. In this particular case "sizeof (u16 **)" happens to be equal
> to "sizeof (u16 *)", but this is not a portable assumption.
> > 767 tmp_files = malloc(count * sizeof(*files));
The change in this patch fixes the ambiguity.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Fixes: CID 316361
For readability use *tmp_files instead of tmp_files[0]
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Add support for authenticating uefi capsules. Most of the signature
verification functionality is shared with the uefi secure boot
feature.
The root certificate containing the public key used for the signature
verification is stored as part of the device tree blob. The root
certificate is stored as an efi signature list(esl) file -- this file
contains the x509 certificate which is the root certificate.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
Although the function description states the caller must provide a
sufficient buffer, it's better to have in function checks that the
destination buffer can hold the intended value.
So let's add an extra argument with the buffer size and check that
before doing any copying.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
In this commit, a very simple firmware management protocol driver
is implemented. It will take a binary image in a capsule file and
apply the data using dfu backend storage drivers via dfu_write_by_alt()
interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
In this commit, a very simple firmware management protocol driver
is implemented. It will take a common FIT image firmware in a capsule
file and apply the data using dfu backend storage drivers via
update_fit() interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Fit image is a common file format for firmware update on U-Boot, and
this protocol works neatly just as a wrapper for one.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID,
is handled as a firmware update object.
What efi_update_capsule() basically does is to load any firmware management
protocol (or fmp) drivers contained in a capsule, find out an appropriate
fmp driver and then invoke its set_image() interface against each binary
in a capsule.
In this commit, however, loading drivers is not supported.
The result of applying a capsule is set to be stored in "CapsuleXXXX"
variable, but its implementation is deferred to a fmp driver.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
|
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
Please note that U-Boot itself has no notion of "boot device" and
all the capsule files to be executed will be detected only if they
are located in a specific directory, \EFI\UpdateCapsule, on a device
that is identified as a boot device by "BootXXXX" variables.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
|
