- Jul 02, 2021
-
-
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 authored
After each reboot we must clear flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable OsIndications. Signed-off-by: -
Improve efi_query_variable_info() to check the parameter settings and return correct error code according to the UEFI Specification 2.9, and the Self Certification Test (SCT) II Case Specification, June 2017, chapter 4.1.4 QueryVariableInfo(). Reported-by:
Kazuhiko Sakamoto <sakamoto.kazuhiko@socionext.com> Signed-off-by:
Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by:
-
Heinrich Schuchardt authored
After if we should use parentheses to keep the code readable. Fixes: a95f4c88 ("efi_loader: NULL dereference in EFI console") Signed-off-by:
-
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:
-
Chapter 23 of the EFI spec (rev 2.9) says: "A specific updatable hardware firmware store must be represented by exactly one FMP instance". This is not the case for us, since both of our FMP protocols can be installed at the same time because they are controlled by a single 'dfu_alt_info' env variable. So make the config options depend on each other and allow the user to install one of them at any given time. If we fix the meta-data provided by the 'dfu_alt_info' in the future, to hint about the capsule type (fit or raw) we can revise this and enable both FMPs to be installed, as long as they target different firmware hardware stores Note that we are not using a Kconfig 'choice' on purpose, since we want to allow both of those to be installed and tested in sandbox Signed-off-by:
-
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:
-
- Jun 28, 2021
-
-
If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled, wherever original env is placed anywhere, it should be relocated to the right address. Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in setup_reloc() and env address gd->env_addr is relocated by the offset in initr_reloc_global_data(). gd->env_addr = (orig env) + gd->reloc_off = (orig env) + (gd->relocaddr - SYS_TEXT_BASE) However, SYS_TEXT_BASE isn't always runtime base address when POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is out of memory location and memory exception will occur. There is a difference between linked address such as SYS_TEXT_BASE and runtime base address. In _main, the difference is calculated as "run-vs-link" offset. The env_addr should also be added to the offset to fix the address. gd->env_addr = (orig env) + ("run-vs-link" offset) + gd->reloc_off = (orig env) + (SYS_TEXT_BASE - _start) + (gd->relocaddr - SYS_TEXT_BASE) = (orig env) + (gd->relocaddr - _start) Cc: Marek Vasut <marex@denx.de> Signed-off-by:Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by:
Marek Vasut <marex@denx.de> Tested-by:
-
Commit e4f8e543("smbios: Drop the unused Kconfig options") break SMBIOS tables. The reason is that the patch drops the Kconfig options *after* removing the code using them, but that changes the semantics of the code completely. Prior to the change a non NULL value was used in the 'product' and 'manufacturer ' fields. Chapter 6.2 of the DMTF spec requires Manufacturer and Product Name to be non-null on some of the tables. So let's add sane defaults for Type1/2/3. * Before the patchset: <snip> Handle 0x0002, DMI type 2, 14 bytes Base Board Information Manufacturer: Not Specified Product Name: Not Specified Version: Not Specified Serial Number: Not Specified Asset Tag: Not Specified Features: Board is a hosting board Location In Chassis: Not Specified Chassis Handle: 0x0000 Type: Motherboard Invalid entry length (0). DMI table is broken! Stop. * After the patchset: <snip> Handle 0x0005, DMI type 32, 11 bytes System Boot Information Status: No errors detected Handle 0x0006, DMI type 127, 4 bytes End Of Table Fixes: e4f8e543 ("smbios: Drop the unused Kconfig options") Signed-off-by:
-
We currently define the EFI support of an SMBIOS table as the third bit of "BIOS Characteristics Extension Byte 1". The latest DMTF spec defines it on "BIOS Characteristics Extension Byte 2". Signed-off-by:
-
Heinrich Schuchardt authored
Use 'Return:' instead of '@return:'. Signed-off-by: -
Heinrich Schuchardt authored
According to chapter 7.1 "Event, Timer, and Task Priority Services" TPL_HIGH_LEVEL should not be exposed to applications and drivers. According to the discussion with EDK II contributors this implies that CreateEvent() shall not allow to create events with TPL_HIGH_LEVEL. Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com> Signed-off-by:
Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
-
- Jun 11, 2021
-
-
Copy the best rational approximation calculation routines from Linux. Typical usecase for these routines is to calculate the M/N divider values for PLLs to reach a specific clock rate. This is based on linux kernel commit: "lib/math/rational.c: fix possible incorrect result from rational fractions helper" (sha1: 323dd2c3ed0641f49e89b4e420f9eef5d3d5a881) Signed-off-by:
Tero Kristo <t-kristo@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com> Signed-off-by:
Tero Kristo <kristo@kernel.org>
-
- Jun 09, 2021
-
-
Heinrich Schuchardt authored
Brackets '[' need to be escaped to avoid a build warning lib/efi_loader/efi_image_loader.c:223: WARNING: Inline strong start-string without end-string. Signed-off-by:Masahisa Kojima <masahisa.kojima@linaro.org>
-
- Jun 08, 2021
-
-
Heinrich Schuchardt authored
If opening a file fails, the file handle pointer is not valid and must not be dereferenced. Signed-off-by: -
Heinrich Schuchardt authored
If we want to address partition 15 of virtio block device 11, we have to write: virtio b:f When calling sprintf() we must use %x for the device and partition numbers. Signed-off-by: -
At present print_buffer() outputs a hex dump but it is not possible to place this dump in a string. Refactor it into a top-level function which does the printing and a utility function that dumps a line into a string. This makes the code more generally useful. Signed-off-by:Simon Glass <sjg@chromium.org>
-
If a long hexdump is initated the user may wish to interrupt it. Add support for this. Signed-off-by: -
At present print_hex_dump() only supports either 16- or 32-byte lines. With U-Boot we want to support any line length up to a maximum of 64. Update the function to support this, with 0 defaulting to 16, as with print_buffer(). Signed-off-by: -
The current implementation outputs an address as a pointer. Update the code to use an address instead, respecting the 32/64 nature of the CPU. Add some initial tests copied from print_test_display_buffer(), just the ones that can pass with the current implementation. Note that for this case print_hex_dump() and print_bufffer() produce the same result. For now the tests are duplicated sine we have separate functions. Signed-off-by: -
Move the comments to the header file so people can find the function info without digging in the implementation. Fix up the code style and add an enum for the first arg. Signed-off-by: -
At present with print_buffer() U-Boot shows four spaces between the hex and ASCII data. Two seems enough and matches print_hex_dump(). Change it. Signed-off-by:
-
- Jun 07, 2021
-
-
Add lmb_dump_region() function, to simplify lmb_dump_all_force(). This patch is based on Linux memblock dump function. An example of bdinfo output is: ..... fdt_size = 0x000146a0 FB base = 0xfdd00000 lmb_dump_all: memory.cnt = 0x1 memory[0] [0xc0000000-0xffffffff], 0x40000000 bytes flags: 0 reserved.cnt = 0x6 reserved[0] [0x10000000-0x10045fff], 0x00046000 bytes flags: 4 reserved[1] [0x30000000-0x3003ffff], 0x00040000 bytes flags: 4 reserved[2] [0x38000000-0x3800ffff], 0x00010000 bytes flags: 4 reserved[3] [0xe8000000-0xefffffff], 0x08000000 bytes flags: 4 reserved[4] [0xfbaea344-0xfdffffff], 0x02515cbc bytes flags: 0 reserved[5] [0xfe000000-0xffffffff], 0x02000000 bytes flags: 4 arch_number = 0x00000000 TLB addr = 0xfdff0000 .... Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: -
Add a new function lmb_is_reserved_flags to check if an address is reserved with a specific flags. This function can be used to check if an address was reserved with no-map flags with: lmb_is_reserved_flags(lmb, addr, LMB_NOMAP); Signed-off-by:Patrick Delaunay <patrick.delaunay@foss.st.com> -
Add "flags" in lmb_property to save the "no-map" property of reserved region and a new function lmb_reserve_flags() to check this flag. The default allocation use flags = LMB_NONE. The adjacent reserved memory region are merged only when they have the same flags value. This patch is partially based on flags support done in Linux kernel mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is aligned with MEMBLOCK_NOMAP value. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by:
-
- Jun 01, 2021
-
-
If a chunk was larger than 4GiB, then chunk_data_sz would overflow and blkcnt would not be calculated correctly. Upgrade it to a u64 and cast its multiplicands as well. Also fix bytes_written while we're at it. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Reviewed-by:
Heiko Schocher <hs@denx.de>
-
- May 28, 2021
-
-
"TCG PC Client Platform Firmware Profile Specification" requires to measure every attempt to load and execute a OS Loader(a UEFI application) into PCR[4]. This commit adds the PE/COFF image measurement, extends PCR, and appends measurement into Event Log. Acked-by:
-
The hash_calculate() symbol is provided by hash-checksum.c. It depends on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y. The issue is that hash_calculate() is used by the efi_loader, irregardless of CONFIG_FIT_SIGNATURE. As pointed out in commit 87316da0 ("lib: introduce HASH_CALCULATE option"), enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect. To resolve this, use CONFIG_HASH as the compile switch for hash-checksum.c. This ensures that all dependencies are compiled, and is the most natural Kconfig to use. There is the issue of having to 'select HASH' in a couple of places that already 'select SHA256'. This is a deeper problem with how hashes are organized, and fixing it is beyonf the scope of this change. Signed-off-by:
Alexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by:
-
When we think of Kconfig, we usually think of features that we like to enable or not. Ideally, we wouldn't use Kconfig to fix a build issue, although sometimes it might make sense. With Kconfig it's hard to guarantee that the fix is universal. We can only say that it works for the set of tested configurations. In the majority of cases, it's preferable to let the linker figure things out for us. The reverted commit attempted to fix a build issue by adding an invisible Kconfig option. This is wrong in several ways: It invents a new Kconfig variable when CONFIG_HASH already exists for the same purpose. Second, hash-checksum.c makes use of the hash_progressive_lookup_algo() symbol, which is only provided with CONFIG_HASH, but this dependency was not expressed in the reverted patch. It feels like Kconfig is turning into a listing of all available source files, and a buffet to 'select' which ones to compile. The purpose of this revert is to enable the next change to make use of CONFIG_HASH instead of adding to Kconfig. This reverts commit 87316da0. Signed-off-by:
-
Coverity reported 3 warnings on the current code. CID 331856, 331855, 331854 on the latest scan. Fix the rest of the warnings by initializing the variables before passing them to tpm2_get_pcr_info(). In order to avoid future warnings and errors initialize them to 0 within the function as well, since the values are always OR'ed after querying the hardware. Signed-off-by:
-
- May 25, 2021
-
-
Compiling with -Wextra produces a number of (harmless) warnings for the EFI TCG2 protocol. Let's fix those in case we ever enable the flag on the EFI subsystem Signed-off-by: -
Heinrich Schuchardt authored
Before this patch efi_dp_from_name() only accommodated a maximum file path length of 31 characters. This leads to boot failures due to file name truncation. Allow arbitrary path lengths. Signed-off-by: -
This is preparation for PE/COFF measurement support. PE/COFF image hash calculation is same in both UEFI Secure Boot image verification and measurement in measured boot. PE/COFF image parsing functions are gathered into efi_image_loader.c, and exposed even if UEFI Secure Boot is not enabled. This commit also adds the EFI_SIGNATURE_SUPPORT option to decide if efi_signature.c shall be compiled. Signed-off-by:
-
Heinrich Schuchardt authored
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:
-
- May 24, 2021
-
-
When building with LTO, the system libc's `errno` variable used in arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in lib/errno.c) with the following error: .../ld: errno@@GLIBC_PRIVATE: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in /tmp/u-boot.EQlEXz.ltrans0.ltrans.o To avoid this conflict use different asm label for this variable when CONFIG_SANDBOX is enabled. Signed-off-by:Marek Behún <marek.behun@nic.cz> Reviewed-by:
Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: -
When compiling with LTO, the compiler fails with an error saying that `crc_table` causes a section type conflict with `efi_var_buf`. This is because both are declared to be in the same section (via macro `__efi_runtime_data`), but one is const while the other is not. Put this variable into the section .rodata.efi_runtime, instead of .data.efi_runtime, via macro __efi_runtime_rodata. Signed-off-by:
Heinrich Schuchardt <xypron.gpk@gmx.de>
-
Add $(CFLAGS_EFI) and remove $(CFLAGS_NON_EFI) for efi_selftest_miniapp_exception.o. The removal is needed when compiling with LTO - this object file needs to be compiled without -flto. The adding is for consistency with other miniapps. Signed-off-by:
-
It seems that sometimes (happening on ARM64, for example with turris_mox_defconfig) GCC, when linking with LTO, changes the symbol names of some functions, for example lib/string.c's memcpy() function to memcpy.isra.0. This is a problem however when GCC for a code such as this: struct some_struct *info = get_some_struct(); struct some struct tmpinfo; tmpinfo = *info; emits a call to memcpy() by builtin behaviour, to copy *info to tmpinfo. This then results in the following linking error: .../lz4.c:93: undefined reference to `memcpy' .../uuid.c:206: more undefined references to `memcpy' follow GCC's documentation says this about -nodefaultlibs option: The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. Make these functions visible by using the __used macro to avoid this error. Signed-off-by:
-
This commit does the same thing as Linux commit 33def8498fdd. Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Signed-off-by:Bin Meng <bmeng.cn@gmail.com>
Reviewed-by:
-
- May 19, 2021
-
-
Bin Meng authoredGenerally speaking BINMAN_FDT makes sense for OF_SEPARATE or OF_EMBED. For the other OF_CONTROL methods, it's quite possible binman node is not available as binman is invoked during the build phase instead of runtime. Let's only turn it on for OF_SEPARATE or OF_EMBED by default. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com>
Reviewed-by:
-
