summaryrefslogtreecommitdiff
path: root/lib/efi_loader
Commit message (Collapse)AuthorAgeFilesLines
* efi_loader: Select EVENT as wellJan Kiszka2022-05-071-0/+1
| | | | | | | | | | | | | | Fixes WARNING: unmet direct dependencies detected for EVENT_DYNAMIC Depends on [n]: EVENT [=n] Selected by [y]: - EFI_LOADER [=y] && OF_LIBFDT [=y] && ... and the succeeding build breakage. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: bootmgr: add booting from removable mediaAKASHI Takahiro2022-05-031-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under the current implementation, booting from removable media using a architecture-specific default image name, say BOOTAA64.EFI, is supported only in distro_bootcmd script. See the commit 74522c898b35 ("efi_loader: Add distro boot script for removable media"). This is, however, half-baked implementation because 1) UEFI specification requires this feature to be implemented as part of Boot Manager's responsibility: 3 - Boot Manager 3.5.1 Boot via the Simple File Protocol When booting via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, the FilePath will start with a device path that points to the device that implements the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the EFI_BLOCK_IO_PROTOCOL. The next part of the FilePath may point to the file name, including subdirectories, which contain the bootable image. If the file name is a null device path, the file name must be generated from the rules defined below. ... 3.5.1.1 Removable Media Boot Behavior To generate a file name when none is present in the FilePath, the firmware must append a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI ... 2) So (1) entails the hehavior that the user's preference of boot media order should be determined by Boot#### and BootOrder variables. With this patch, the semantics mentioned above is fully implemented. For example, if you want to boot the system from USB and SCSI in this order, * define Boot0001 which contains only a device path to the USB device (without any file path/name) * define Boot0002 which contains only a device path to the SCSI device, and * set BootOrder to Boot0001:Boot0002 To avoid build error for sandbox, default file name "BOOTSANDBOX.efi" is defined even if it is out of scope of UEFI specification. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> On sandbox use binary name corresponding to host architecture. Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: export efi_locate_device_handle()AKASHI Takahiro2022-05-031-4/+3
| | | | | | | | | This function will be used in the next commit where some behavior of EFI boot manager will be expanded. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* lib: fix selection of CONFIG_CHARSETHeinrich Schuchardt2022-05-031-0/+1
| | | | | | | | | lib/charset.c is not optional for EFI_APP || EFI_LOADER || UFS || UT_UNICODE. These must select CONFIG_CHARSET. Fixes: 726cd9836db0 ("efi: Make unicode printf available to the app") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: reset colors before clearing screenHeinrich Schuchardt2022-05-031-2/+2
| | | | | | | When resetting the text console the colors have to be set before clearing the screen. Otherwise the background color may be wrong. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: disk: allow blk devices even without UCLASS_PARTITIONAKASHI Takahiro2022-04-291-14/+15
| | | | | | | | | | | While GPT partition is mandated in UEFI specification, CONFIG_PARTITION is seen optional under the current implementation. So modify efi_disk_rw_blocks() to allow accepting UCLASS_BLK devices. Fixes: commit d97e98c887ed ("efi_loader: disk: use udevice instead of blk_desc") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Mark Kettenis <kettenis@openbsd.org>
* efi_loader: simplify efi_add_conventional_memory_map()Heinrich Schuchardt2022-04-291-1/+1
| | | | | | Remove redundant constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: simplify try_load_entry()Heinrich Schuchardt2022-04-291-6/+2
| | | | | | | Use function efi_create_indexed_name() to create the BootXXXX variable name. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: don't call log with __func__ as parameterHeinrich Schuchardt2022-04-291-4/+3
| | | | | | | | The log functions print file name, line number, and function name if selected via the log command or customizing. Don't print the function name twice. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: disk: use udevice instead of blk_descAKASHI Takahiro2022-04-231-6/+16
| | | | | | | | | | | | 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>
* efi_loader: disk: not delete BLK device for BLK(IF_TYPE_EFI_LOADER) devicesAKASHI Takahiro2022-04-231-2/+6
| | | | | | | | | | | | | | | 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>
* efi_loader: disk: a helper function to delete efi_disk objectsAKASHI Takahiro2022-04-231-0/+88
| | | | | | | | | | | | | | | 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>
* efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI_LOADER) devicesAKASHI Takahiro2022-04-231-3/+11
| | | | | | | | | | | | | | | 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>
* efi_loader: disk: a helper function to create efi_disk objects from udeviceAKASHI Takahiro2022-04-233-77/+131
| | | | | | | | | | | | | 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>
* efi_loader: split efi_init_obj_list() into two stagesAKASHI Takahiro2022-04-231-9/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* efi_loader: disk: compile efi_disk when CONFIG_BLKAKASHI Takahiro2022-04-231-1/+1
| | | | | | | | 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>
* efi_loader: PARTITION_UUIDS should be optionalAKASHI Takahiro2022-04-232-3/+8
| | | | | | | | | | 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 17f8cda505e3 ("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>
* efi_loader: simplify efi_serialize_load_option()Heinrich Schuchardt2022-04-151-1/+1
| | | | | | Use u16_strsize(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: EFI_HII_STRING_PROTOCOL.GetString()Heinrich Schuchardt2022-04-151-1/+1
| | | | | | Use u16_strsize(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* FMP: Remove GUIDs for FIT and raw imagesSughosh Ganu2022-04-151-4/+0
| | | | | | | | | 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>
* efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabledSughosh Ganu2022-04-152-0/+7
| | | | | | | | | | | | | | | | | | | | | 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>
* capsule: Put a check for image index before the updateSughosh Ganu2022-04-151-3/+5
| | | | | | | | | | | | | | | | | | 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>
* capsule: FMP: Populate the image descriptor array from platform dataSughosh Ganu2022-04-151-69/+29
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* efi_loader: Use sysreset instead of reset commandMasami Hiramatsu2022-04-092-2/+4
| | | | | | | | | | | | 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_loader: Make efi_load_capsule_drivers() available even if ↵Masami Hiramatsu2022-04-091-30/+30
| | | | | | | | | | | 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>
* efi_loader: optional persistence of variablesTom Saeger2022-04-091-1/+8
| | | | | | | | | | Since be66b89da306 ("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>
* Merge branch 'next'Tom Rini2022-04-041-1/+0
|\ | | | | | | Signed-off-by: Tom Rini <trini@konsulko.com>
| * video: Drop references to CONFIG_VIDEO et alSimon Glass2022-03-281-1/+0
| | | | | | | | | | | | | | | | | | | | | | 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>
* | efi_loader: initrddump: Actually use the custom CFLAGSAndy Shevchenko2022-03-311-1/+1
|/ | | | | | | | | | | | | | | | | | 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: 65ab48d69ddb ("efi_selftest: provide initrddump test tool") Fixes: 9c045a49a9c9 ("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>
* efi_loader: initrddump: drain input before promptHeinrich Schuchardt2022-03-261-4/+10
| | | | | | | | | | 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>
* efi_loader: nocolor command line attr for initrddump.efiHeinrich Schuchardt2022-03-261-9/+68
| | | | | | | | 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>
* efi_loader: typo devie-pathHeinrich Schuchardt2022-03-261-1/+1
| | | | | | | %s/devie-path/device-path/ Reported-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: move dtbdump.c, initrddump.c to lib/efi_loaderHeinrich Schuchardt2022-03-203-0/+1000
| | | | | | | | | 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>
* efi_loader: remove efi_disk_is_system_part()Heinrich Schuchardt2022-03-202-31/+9
| | | | | | | | | | | 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>
* efi_loader: support booting via short-form device-pathHeinrich Schuchardt2022-03-201-10/+10
| | | | | | | | | | 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: 0e074d12393b ("efi_loader: carve out efi_load_image_from_file()") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: efi_dp_find_obj() add protocol checkHeinrich Schuchardt2022-03-204-10/+19
| | | | | | | 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_loader: fix efi_dp_find_obj()Heinrich Schuchardt2022-03-201-49/+61
| | | | | | | 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>
* efi_loader: export efi_dp_shorten()Heinrich Schuchardt2022-03-201-8/+13
| | | | | | Rename function shorten_path() to efi_dp_shorten() and export it. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* efi_loader: Set variable attributes when EFI_BUFFER_TOO_SMALL is returnedIlias Apalodimas2022-03-201-11/+20
| | | | | | | | | | | 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>
* efi_loader: copy GUID in InstallProtocolInterface()Heinrich Schuchardt2022-03-122-8/+8
| | | | | | | | | | 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>
* efi_loader: update the timing of enabling and disabling EFI watchdogMasahisa Kojima2022-02-261-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* efi_loader: test/py: Reset system after capsule update on diskMasami Hiramatsu2022-02-261-2/+16
| | | | | | | | | | | | | | | 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>
* efi_loader: use efi_update_capsule_firmware() for capsule on diskMasami Hiramatsu2022-02-261-1/+1
| | | | | | | | | | | | | | | | | 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>
* efi_loader: fix uefi secure boot with intermediate certsIlias Apalodimas2022-02-261-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* efi_loader: fix dual signed image certificationIlias Apalodimas2022-02-111-70/+18
| | | | | | | | | | | | | | | | | | | | | | | 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>
* efi: Drop unnecessary calls to blk_find_device()Simon Glass2022-02-051-12/+2
| | | | | | | | 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>
* efi: Use device_get_uclass_id() where appropriateSimon Glass2022-02-051-5/+5
| | | | | | | | | | | 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>
* efi_loader: add handle for UARTHeinrich Schuchardt2022-02-051-27/+25
| | | | | | | 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>
* efi_loader: fix text output for Uart() DP nodesHeinrich Schuchardt2022-02-051-9/+19
| | | | | | | | | | | | | 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>
* efi_loader: use %zu to print efi_uintn_t in FMP driverHeinrich Schuchardt2022-02-051-2/+2
| | | | | | For printing an unsigned value we should use %u and not %d. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
View Lorry Controller Status