April 2024 - U-Boot

[PATCH] cmd: sysboot: null check filename
by Caleb Connolly 10 Apr '24

10 Apr '24

Currently if ${bootfile} is unset and sysboot is invoked with no filename specified then U-Boot will crash will a null-pointer dereference. Add the missing check and a matching error print. Fixes: 993c912d304d ("cmd: sysboot: Create a sysboot command dedicated file") Signed-off-by: Caleb Connolly <caleb.connolly(a)linaro.org> --- cmd/sysboot.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/cmd/sysboot.c b/cmd/sysboot.c index 63a7806debe4..d14c570d96ab 100644 --- a/cmd/sysboot.c +++ b/cmd/sysboot.c @@ -76,8 +76,12 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int argc, } if (argc < 6) { filename = env_get("bootfile"); + if (!filename) { + printf("Specify a filename or set the ${bootfile} environment variable\n"); + return 1; + } } else { filename = argv[5]; env_set("bootfile", filename); } -- 2.44.0

2 1

[PATCH] arm64: Fix map_range() not splitting mapped blocks
by Pierre-Clément Tosi 10 Apr '24

10 Apr '24

The implementation of map_range() creates the requested mapping by walking the page tables, iterating over multiple PTEs and/or descending into existing table mappings as needed. When doing so, it assumes any pre-existing valid PTE to be a table mapping. This assumption is wrong if the platform code attempts to successively map two overlapping ranges where the latter intersects a block mapping created for the former. As a result, map_range() treats the existing block mapping as a table mapping and descends into it i.e. starts interpreting the previously-mapped range as an array of PTEs, writing to them and potentially even descending further (extra fun with MMIO ranges!). Instead, pass any valid non-table mapping to split_block(), which ensures that it actually was a block mapping (calls panic() otherwise) before splitting it. Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity") Signed-off-by: Pierre-Clément Tosi <ptosi(a)google.com> --- arch/arm/cpu/armv8/cache_v8.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index 697334086f..57d06f0575 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -326,6 +326,8 @@ static void map_range(u64 virt, u64 phys, u64 size, int level, /* Going one level down */ if (pte_type(&table[i]) == PTE_TYPE_FAULT) set_pte_table(&table[i], create_table()); + else if (pte_type(&table[i]) != PTE_TYPE_TABLE) + split_block(&table[i], level); next_table = (u64 *)(table[i] & GENMASK_ULL(47, PAGE_SHIFT)); next_size = min(map_size - (virt & (map_size - 1)), size); -- 2.44.0.291.gc1ea87d7ee-goog -- Pierre

5 13

[PATCH v1 0/4] Enable SetvariableRT
by Ilias Apalodimas 10 Apr '24

10 Apr '24

Hi all, This is an updated version of [0]. When EFI variables are stored on file we don't allow SetVariableRT, since the OS doesn't know how to access or write that file. At the same time keeping the U-Boot drivers alive in runtime sections and performing writes from the firmware is dangerous -- if at all possible. For GetVariableRT we copy runtime variables in RAM and expose them to the OS. Add a Kconfig option and provide SetVariableRT using the same memory back end. The OS will be responsible for syncing the RAM contents to the file, otherwise any changes made during runtime won't persist reboots. It's worth noting that the variable store format is defined in EBBR [1] and authenticated variables are explicitly prohibited, since they have to be stored on a medium that's tamper and rollback protected. The original RFC was just enabling the memory back end. This is a more complete version and we should be able, with small adjustments of userspace tools, fix SetVariableRT. If enabled the firmware will add two new RO EFI variables after ExitBootServices. RTStorageVolatile -- contains the filename, relative to the ESP VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can be copied to the file defined by RTStorageVolatile. If any errors occur during the variable init, the firmware will delete them and adjust the RT_PROP table accordingly, disabling SetvarRT. - pre-patch $~ mount | grep efiva efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,relatime) $~ efibootmgr -n 0001 Could not set BootNext: Read-only file system - post-patch $~ mount | grep efiva efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) , disabling SetvarRT. $~ efibootmgr -n 0001 BootNext: 0001 BootCurrent: 0000 BootOrder: 0000,0001 Boot0000* debian HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x100000)/File(EFI\debian\grubaa64.efi) Boot0001* virtio 0 VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,0000000000000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,850000001f000000)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,1600850000000000){auto_created_boot_option} $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c Name: "BootNext" Attributes: Non-Volatile Boot Service Access Runtime Service Access Value: 00000000 01 00 [0] https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodimas@li… [1] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-s… Changes since the RFC: - Return EFI_INVALID_PARAM if attributes are not volatile - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables - Add 2 EFI variables and allow userspace to write the file - Add selftests Ilias Apalodimas (4): efi_loader: conditionally enable SetvariableRT efi_loader: Add OS notifications for SetVariableRT in RAM efi_loader: add an EFI variable with the variable file contents efi_selftest: add tests for setvariableRT include/efi_loader.h | 4 + include/efi_variable.h | 15 +- lib/efi_loader/Kconfig | 16 ++ lib/efi_loader/efi_boottime.c | 2 + lib/efi_loader/efi_runtime.c | 1 + lib/efi_loader/efi_var_common.c | 43 ++-- lib/efi_loader/efi_var_file.c | 1 - lib/efi_loader/efi_var_mem.c | 90 +++----- lib/efi_loader/efi_variable.c | 210 +++++++++++++++++- lib/efi_loader/efi_variable_tee.c | 1 - .../efi_selftest_variables_runtime.c | 116 +++++++++- 11 files changed, 401 insertions(+), 98 deletions(-) -- 2.37.2

3 21

[PATCH] gpio: pca953x_gpio: support optional reset-gpios property
by Rasmus Villemoes 10 Apr '24

10 Apr '24

The DT bindings for the pca953x family has an optional reset-gpios property. If present, ensure that the device is taken out of reset before attempting to read from it. Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> --- drivers/gpio/pca953x_gpio.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpio/pca953x_gpio.c b/drivers/gpio/pca953x_gpio.c index b0c66d18317..24b0732f89a 100644 --- a/drivers/gpio/pca953x_gpio.c +++ b/drivers/gpio/pca953x_gpio.c @@ -306,6 +306,7 @@ static int pca953x_probe(struct udevice *dev) struct pca953x_info *info = dev_get_plat(dev); struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev); char name[32], label[8], *str; + struct gpio_desc reset; int addr; ulong driver_data; int ret; @@ -321,6 +322,13 @@ static int pca953x_probe(struct udevice *dev) driver_data = dev_get_driver_data(dev); + /* If a reset-gpios property is present, take the device out of reset. */ + ret = gpio_request_by_name(dev, "reset-gpios", 0, &reset, GPIOD_IS_OUT); + if (ret && ret != -ENOENT) { + dev_err(dev, "requesting reset-gpios failed: %d\n", ret); + return ret; + } + info->gpio_count = driver_data & PCA_GPIO_MASK; if (info->gpio_count > MAX_BANK * BANK_SZ) { dev_err(dev, "Max support %d pins now\n", MAX_BANK * BANK_SZ); -- 2.40.1.1.g1c60b9335d

2 3

[PATCH 1/1] api: add missing cookie checks for network access
by Heinrich Schuchardt 10 Apr '24

10 Apr '24

dev_write_net() and dev_read_net() should validate the provided cookie. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- api/api_net.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/api/api_net.c b/api/api_net.c index 7515c26e8b4..0b931a80787 100644 --- a/api/api_net.c +++ b/api/api_net.c @@ -72,14 +72,16 @@ int dev_enum_net(struct device_info *di) int dev_write_net(void *cookie, void *buf, int len) { - /* XXX verify that cookie points to a valid net device??? */ + if (!dev_valid_net(cookie)) + return API_ENODEV; return eth_send(buf, len); } int dev_read_net(void *cookie, void *buf, int len) { - /* XXX verify that cookie points to a valid net device??? */ + if (!dev_valid_net(cookie)) + return API_ENODEV; return eth_receive(buf, len); } -- 2.43.0

2 3

[PATCH] xilinx: common: Fix MAC address read from EEPROM
by Petr Zejdl 10 Apr '24

10 Apr '24

The upper-to-lowercase character conversion now avoids altering the MAC address field. In the previous version, this alteration corrupted the MAC address. Signed-off-by: Petr Zejdl <petr.zejdl(a)cern.ch> --- board/xilinx/common/board.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c index 66edf857f1..49dc5d10cc 100644 --- a/board/xilinx/common/board.c +++ b/board/xilinx/common/board.c @@ -101,10 +101,14 @@ static void xilinx_eeprom_legacy_cleanup(char *eeprom, int size) for (i = 0; i < size; i++) { byte = eeprom[i]; - /* Remove all non printable chars but ignore MAC address */ - if ((i < offsetof(struct xilinx_legacy_format, eth_mac) || - i >= offsetof(struct xilinx_legacy_format, unused1)) && - (byte < '!' || byte > '~')) { + /* Ignore MAC address */ + if (i >= offsetof(struct xilinx_legacy_format, eth_mac) && + i < offsetof(struct xilinx_legacy_format, unused1)) { + continue; + } + + /* Remove all non printable chars */ + if (byte < '!' || byte > '~') { eeprom[i] = 0; continue; } -- 2.31.1

2 1

[RFC PATCH] efi_loader: Fix EFI_VARIABLE_APPEND_WRITE hash check
by Weizhao Ouyang 10 Apr '24

10 Apr '24

According to UEFI v2.10 spec section 8.2.6, if a caller invokes the SetVariables() service, it will produce a digest from hash(VariableName, VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the firmware that implements the SetVariable() service will compare the digest with the result of applying the signer’s public key to the signature. For EFI variable append write, efitools sign-efi-sig-list has an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will drop this attribute in efi_set_variable_int(). So if a caller uses "sign-efi-sig-list -a" to create the authenticated variable, this append write will fail in the u-boot due to "hash check failed". This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure that the hash check is correct. And also update the "test_efi_secboot" test case to compliance with the change. Signed-off-by: Weizhao Ouyang <o451686892(a)gmail.com> --- lib/efi_loader/efi_variable.c | 3 +-- test/py/tests/test_efi_secboot/conftest.py | 10 ++++++++++ test/py/tests/test_efi_secboot/test_authvar.py | 4 ++-- test/py/tests/test_efi_secboot/test_signed.py | 10 +++++----- 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c index 40f7a0fb10..f41aa8f9ad 100644 --- a/lib/efi_loader/efi_variable.c +++ b/lib/efi_loader/efi_variable.c @@ -259,7 +259,6 @@ efi_status_t efi_set_variable_int(const u16 *variable_name, /* check if a variable exists */ var = efi_var_mem_find(vendor, variable_name, NULL); append = !!(attributes & EFI_VARIABLE_APPEND_WRITE); - attributes &= ~(u32)EFI_VARIABLE_APPEND_WRITE; delete = !append && (!data_size || !attributes); /* check attributes */ @@ -275,7 +274,7 @@ efi_status_t efi_set_variable_int(const u16 *variable_name, /* attributes won't be changed */ if (!delete && - ((ro_check && var->attr != attributes) || + ((ro_check && var->attr != (attributes & ~(u32)EFI_VARIABLE_APPEND_WRITE)) || (!ro_check && ((var->attr & ~(u32)EFI_VARIABLE_READ_ONLY) != (attributes & ~(u32)EFI_VARIABLE_READ_ONLY))))) { return EFI_INVALID_PARAMETER; diff --git a/test/py/tests/test_efi_secboot/conftest.py b/test/py/tests/test_efi_secboot/conftest.py index ff7ac7c810..0fa0747fc7 100644 --- a/test/py/tests/test_efi_secboot/conftest.py +++ b/test/py/tests/test_efi_secboot/conftest.py @@ -64,6 +64,12 @@ def efi_boot_env(request, u_boot_config): check_call('cd %s; %scert-to-efi-sig-list -g %s db1.crt db1.esl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key db db1.esl db1.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) + # db2 (APPEND_WRITE) + check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db2/ -keyout db2.key -out db2.crt -nodes -days 365' + % mnt_point, shell=True) + check_call('cd %s; %scert-to-efi-sig-list -g %s db2.crt db2.esl; %ssign-efi-sig-list -a -c KEK.crt -k KEK.key db db2.esl db2.auth' + % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), + shell=True) # dbx (TEST_dbx certificate) check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_dbx/ -keyout dbx.key -out dbx.crt -nodes -days 365' % mnt_point, shell=True) @@ -84,6 +90,10 @@ def efi_boot_env(request, u_boot_config): check_call('cd %s; %scert-to-efi-hash-list -g %s -s 256 db1.crt dbx_hash1.crl; %ssign-efi-sig-list -t "2020-04-06" -c KEK.crt -k KEK.key dbx dbx_hash1.crl dbx_hash1.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) + # dbx_hash2 (digest of TEST_db2 certificate, with APPEND_WRITE) + check_call('cd %s; %scert-to-efi-hash-list -g %s -s 256 db2.crt dbx_hash2.crl; %ssign-efi-sig-list -a -c KEK.crt -k KEK.key dbx dbx_hash2.crl dbx_hash2.auth' + % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), + shell=True) # dbx_db (with TEST_db certificate) check_call('cd %s; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx db.esl dbx_db.auth' % (mnt_point, EFITOOLS_PATH), diff --git a/test/py/tests/test_efi_secboot/test_authvar.py b/test/py/tests/test_efi_secboot/test_authvar.py index f99b8270a6..d5aeb65048 100644 --- a/test/py/tests/test_efi_secboot/test_authvar.py +++ b/test/py/tests/test_efi_secboot/test_authvar.py @@ -183,7 +183,7 @@ class TestEfiAuthVar(object): assert 'db:' in ''.join(output) output = u_boot_console.run_command_list([ - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -a -i 4000000:$filesize db']) assert 'Failed to set EFI variable' in ''.join(output) @@ -197,7 +197,7 @@ class TestEfiAuthVar(object): with u_boot_console.log.section('Test Case 3c'): # Test Case 3c, update with correct signature output = u_boot_console.run_command_list([ - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize db', 'printenv -e -n -guid d719b2cb-3d3a-4596-a3bc-dad00e67656f db']) assert 'Failed to set EFI variable' not in ''.join(output) diff --git a/test/py/tests/test_efi_secboot/test_signed.py b/test/py/tests/test_efi_secboot/test_signed.py index 2f862a259a..34719ad1f2 100644 --- a/test/py/tests/test_efi_secboot/test_signed.py +++ b/test/py/tests/test_efi_secboot/test_signed.py @@ -177,7 +177,7 @@ class TestEfiSignedImage(object): with u_boot_console.log.section('Test Case 5b'): # Test Case 5b, authenticated if both signatures are verified output = u_boot_console.run_command_list([ - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize db']) assert 'Failed to set EFI variable' not in ''.join(output) output = u_boot_console.run_command_list([ @@ -201,7 +201,7 @@ class TestEfiSignedImage(object): with u_boot_console.log.section('Test Case 5d'): # Test Case 5d, rejected if both of signatures are revoked output = u_boot_console.run_command_list([ - 'fatload host 0:1 4000000 dbx_hash1.auth', + 'fatload host 0:1 4000000 dbx_hash2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize dbx']) assert 'Failed to set EFI variable' not in ''.join(output) output = u_boot_console.run_command_list([ @@ -223,7 +223,7 @@ class TestEfiSignedImage(object): 'setenv -e -nv -bs -rt -at -i 4000000:$filesize KEK', 'fatload host 0:1 4000000 PK.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize PK', - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize db', 'fatload host 0:1 4000000 dbx_hash1.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize dbx']) @@ -300,7 +300,7 @@ class TestEfiSignedImage(object): 'setenv -e -nv -bs -rt -at -i 4000000:$filesize KEK', 'fatload host 0:1 4000000 PK.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize PK', - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize db', 'fatload host 0:1 4000000 dbx_hash384.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize dbx']) @@ -323,7 +323,7 @@ class TestEfiSignedImage(object): 'setenv -e -nv -bs -rt -at -i 4000000:$filesize KEK', 'fatload host 0:1 4000000 PK.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize PK', - 'fatload host 0:1 4000000 db1.auth', + 'fatload host 0:1 4000000 db2.auth', 'setenv -e -nv -bs -rt -at -a -i 4000000:$filesize db', 'fatload host 0:1 4000000 dbx_hash512.auth', 'setenv -e -nv -bs -rt -at -i 4000000:$filesize dbx']) -- 2.40.1

2 5

[PATCH 0/3] qcom: add clock driver support for SM8550 and SM8650 SoCc
by Neil Armstrong 10 Apr '24

10 Apr '24

Add the GCC and TCSRCC clock driver for the SM8550 & SM8650 SoCs. The GCC driver uses the clk-qcom infrastructure to support GDSCs, Resets and gates. While the TCSRCC is a simpler clock driver which only supports gates. The GCC enable and set_rate callbacks contains some tweaks to setup clocks for Debug UART, SDCard controller and USB. The TCSRCC gates returns the XO frequency, which is used by the Synopsys eUSB2 driver to determine the PHY configuration. In addition, the drivers are enabled in the Qualcomm defconfig. Signed-off-by: Neil Armstrong <neil.armstrong(a)linaro.org> --- Neil Armstrong (3): clk: qcom: Add SM8550 clock driver clk: qcom: Add SM8650 clock driver qcom_defconfig: enable SM8550 & SM8650 clock driver configs/qcom_defconfig | 2 + drivers/clk/qcom/Kconfig | 16 ++ drivers/clk/qcom/Makefile | 2 + drivers/clk/qcom/clock-sm8550.c | 335 ++++++++++++++++++++++++++++++++++++++++ drivers/clk/qcom/clock-sm8650.c | 332 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 687 insertions(+) --- base-commit: f0e6aba1218bca578605697eed8aa94582bf57bb change-id: 20240404-topic-sm8x50-clock-a76f8359b5fb Best regards, -- Neil Armstrong <neil.armstrong(a)linaro.org>

4 10

[PATCH 1/1] efi_loader: 'EFI using ACPI tables at' should be debug message
by Heinrich Schuchardt 10 Apr '24

10 Apr '24

The message "EFI using ACPI tables at %lx\n" is only of interest when debugging. Make it a debug message. Fixes: 085f8db6b98d ("efi: Use the installed ACPI tables") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- lib/efi_loader/efi_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c index 67bbd2a01c0..67bd7f8ca24 100644 --- a/lib/efi_loader/efi_acpi.c +++ b/lib/efi_loader/efi_acpi.c @@ -41,7 +41,7 @@ efi_status_t efi_acpi_register(void) } addr = gd_acpi_start(); - printf("EFI using ACPI tables at %lx\n", addr); + log_debug("EFI using ACPI tables at %lx\n", addr); /* And expose them to our EFI payload */ return efi_install_configuration_table(&acpi_guid, -- 2.43.0

2 1

[PATCH 0/2] arch: zynqmp: Make zynqmp command more accessible.
by Charlie Johnston 10 Apr '24

10 Apr '24

While working on a third-party board using a ZynqMP, I was unable to use the zynqmp command even with the proper config definitions. While that command appears tied to the architecture, it was being included based on the board selection instead. This patch series moves the command to be accessible to any ZynqMP arch based board.

2 3