April 2021 - U-Boot

[PATCH 1/1] efi_loader: memory leak in efi_capsule_scan_dir()
by Heinrich Schuchardt 11 Apr '21

11 Apr '21

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(a)gmx.de> --- lib/efi_loader/efi_capsule.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 9df9c35084..691eda5e0d 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -756,8 +756,11 @@ static efi_status_t efi_capsule_scan_dir(u16 ***files, unsigned int *num) tmp_size = dirent_size; ret = EFI_CALL((*dirh->read)(dirh, &tmp_size, dirent)); if (ret == EFI_BUFFER_TOO_SMALL) { + struct efi_file_info *old_dirent = dirent; + dirent = realloc(dirent, tmp_size); if (!dirent) { + dirent = old_dirent; ret = EFI_OUT_OF_RESOURCES; goto err; } -- 2.30.2

1 0

[PATCH 1/1] board: toradex: apalis-imx8x: fix build warning
by Heinrich Schuchardt 10 Apr '21

10 Apr '21

The length of an underline must match the length of the header. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- doc/board/toradex/apalix-imx8x.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/board/toradex/apalix-imx8x.rst b/doc/board/toradex/apalix-imx8x.rst index efa7e0c72e..e62578b152 100644 --- a/doc/board/toradex/apalix-imx8x.rst +++ b/doc/board/toradex/apalix-imx8x.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0+ Apalis iMX8X V1.1A Module (SoC NXP i.MX8QXP RevB) -========================== +================================================= Quick Start ----------- -- 2.30.2

2 1

[PATCH 01/13] arm: nanopi2: Remove unused code
by Tom Rini 10 Apr '21

10 Apr '21

This platform did not ever enable CONFIG_REVISION_TAG, so the code to set the board_rev environment variable was never enabled. This particular symbol is also only for use with the REVISION ATAG and this platform is new enough to have never supported an ATAG-based Linux Kernel. Cc: Stefan Bosch <stefan_b(a)posteo.net> Signed-off-by: Tom Rini <trini(a)konsulko.com> --- I'd be happy to see this patch replaced by one that enables what I think you meant to be doing and by default. Thanks! --- board/friendlyarm/nanopi2/board.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/board/friendlyarm/nanopi2/board.c b/board/friendlyarm/nanopi2/board.c index 68980536abe9..6e546853b863 100644 --- a/board/friendlyarm/nanopi2/board.c +++ b/board/friendlyarm/nanopi2/board.c @@ -294,16 +294,6 @@ static void set_ether_addr(void) env_set("ethaddr", ethaddr); } -#ifdef CONFIG_REVISION_TAG -static void set_board_rev(void) -{ - char info[64] = {0, }; - - snprintf(info, ARRAY_SIZE(info), "%02x", get_board_rev()); - env_set("board_rev", info); -} -#endif - static void set_dtb_name(void) { char info[64] = {0, }; @@ -435,9 +425,6 @@ int board_late_init(void) { bd_update_env(); -#ifdef CONFIG_REVISION_TAG - set_board_rev(); -#endif set_dtb_name(); set_ether_addr(); -- 2.17.1

8 30

[PATCH v2] efi_loader: esrt: Remove EFI_CALL invocation for efi_create_event
by Sughosh Ganu 10 Apr '21

10 Apr '21

The efi_esrt_register function calls the efi_create_event function through the EFI_CALL macro. For the Arm and RiscV architecture platforms, the EFI_CALL macro, before invoking the corresponding function, modifies the global_data pointer. Before the function calls, the gd is set to app_gd, which is the value used by UEFI app, and after the function call, it is restored back to u-boot's gd. This becomes an issue when the EFI_CALL is used for the function invocation, since the function makes calls to calloc, which dereferences the gd pointer. With the gd pointer being no longer valid, this results in an abort. Since this function is using u-boot's api's, it should not be called through the EFI_CALL macro. Fix this issue by calling the function directly, without the EFI_CALL macro. Signed-off-by: Sughosh Ganu <sughosh.ganu(a)linaro.org> --- Changes since V1: Remove the EFI_CALL macro only for efi_create_event function invocation, and not for the efi_register_protocol_notify invocation, since the later has an EFI_ENTRY function call. lib/efi_loader/efi_esrt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/efi_loader/efi_esrt.c b/lib/efi_loader/efi_esrt.c index 947bdb5e95..461bd4b937 100644 --- a/lib/efi_loader/efi_esrt.c +++ b/lib/efi_loader/efi_esrt.c @@ -490,8 +490,8 @@ efi_status_t efi_esrt_register(void) return ret; } - ret = EFI_CALL(efi_create_event(EVT_NOTIFY_SIGNAL, TPL_CALLBACK, - efi_esrt_new_fmp_notify, NULL, NULL, &ev)); + ret = efi_create_event(EVT_NOTIFY_SIGNAL, TPL_CALLBACK, + efi_esrt_new_fmp_notify, NULL, NULL, &ev); if (ret != EFI_SUCCESS) { EFI_PRINT("ESRT failed to create event\n"); return ret; -- 2.17.1

2 1

[PATCH] efi_loader: esrt: Remove EFI_CALL invocation in efi_esrt_register
by Sughosh Ganu 10 Apr '21

10 Apr '21

The efi_esrt_register function calls efi_create_event and efi_register_protocol_notify functions. These function calls are made through the EFI_CALL macro. For the Arm and RiscV architecture platforms, the EFI_CALL macro, before invoking the corresponding function, modifies the global_data pointer. Before the function calls, the gd is set to app_gd, which is the value used by UEFI app, and after the function call, it is restored back to u-boot's gd. This becomes an issue when the EFI_CALL is used for the two function invocations, since these functions make calls to calloc, which dereferences the gd pointer. With the gd pointer being no longer valid, this results in an abort. Since these functions are using u-boot's api's, they should not be called through the EFI_CALL macro. Fix this issue by calling these functions directly, without the EFI_CALL macro. Signed-off-by: Sughosh Ganu <sughosh.ganu(a)linaro.org> --- This issue can be seen by executing a 'printenv -e' command on an arm architecture platform. Executing the command results in an abort. lib/efi_loader/efi_esrt.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/efi_loader/efi_esrt.c b/lib/efi_loader/efi_esrt.c index 947bdb5e95..141baabb01 100644 --- a/lib/efi_loader/efi_esrt.c +++ b/lib/efi_loader/efi_esrt.c @@ -490,15 +490,15 @@ efi_status_t efi_esrt_register(void) return ret; } - ret = EFI_CALL(efi_create_event(EVT_NOTIFY_SIGNAL, TPL_CALLBACK, - efi_esrt_new_fmp_notify, NULL, NULL, &ev)); + ret = efi_create_event(EVT_NOTIFY_SIGNAL, TPL_CALLBACK, + efi_esrt_new_fmp_notify, NULL, NULL, &ev); if (ret != EFI_SUCCESS) { EFI_PRINT("ESRT failed to create event\n"); return ret; } - ret = EFI_CALL(efi_register_protocol_notify(&efi_guid_firmware_management_protocol, - ev, &registration)); + ret = efi_register_protocol_notify(&efi_guid_firmware_management_protocol, + ev, &registration); if (ret != EFI_SUCCESS) { EFI_PRINT("ESRT failed to register FMP callback\n"); return ret; -- 2.17.1

2 2

Re: Request for documenting the EFI_{ENTRY,EXIT} functions
by Heinrich Schuchardt 10 Apr '21

10 Apr '21

On 4/10/21 2:35 PM, Sughosh Ganu wrote: > hi Heinrich, > For the last one day, i was debugging an issue which i encountered when > I tried to print the uefi env variables. This was seen both on arm64 and > arm32 platforms. I have sent a patch for this fix[1]. > > However, the reason i am writing to you is that, while i was debugging, > i was looking at the functionality of the EFI_CALL macro, along with > EFI_ENTRY AND EFI_EXIT. And i must admit that looking at the function > names and symbol names was a bit confusing. This is because it is kind > of difficult to guess the reference from which these symbols and > functions are named. > > One example is the EFI_CALL macro, in which before the function is > called, there is an assert check for __efi_exit_check. Once the function > call returns, the assert check is for __efi_entry_check. This seems a > bit counter-intuitive -- the call made at EFI_CALL beginning is named > __efi_exit* and the one after the function return is named __efi_entry*. > Same goes for the pointer names used for holding the gd values. There is > an app_gd, and efi_gd. It is not very clear as to which is used where. EFI_ENTRY() is used wherever an API call enters the firmware. EFI_EXIT() is used wherever the firmware is left into the UEFI world. EFI_CALL() replaces the sequence EFI_EXIT, function invocation, EFI_ENTRY. app_gd is register r9/x18 of the UEFI world. efi_gd is register r9/x18 of U-Boot. > > I see that you are the original author of the EFI_MACRO call, and thus EFI_CALL() was introduced by Rob Clark in a095aadffa9. > would be having a pretty good understanding of the nomenclature as well. > So, given how much you trouble me during code review(pun intended :P), I > was thinking to ask you for a favour. I was thinking if we can have a > document which explains these macros, api's and gd pointers in a little > detail. Can you please write such a document whenever you get time so > that it would be useful for people like me. Thanks for your time and > dedication to the u-boot project. > > -sughosh > [1] - https://lists.denx.de/pipermail/u-boot/2021-April/446948.html > <https://lists.denx.de/pipermail/u-boot/2021-April/446948.html> I can create such a document. Best regards Heinrich

1 0

[PULL] Pull request for u-boot master / v2021.07 = u-boot-stm32-20210409
by Patrice CHOTARD 10 Apr '21

10 Apr '21

Hi Tom Please pull the STM32 related patches for u-boot/master, v2021.07: u-boot-stm32-20210409 CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/7103 Thanks, Patrice The following changes since commit b46dd116ce03e235f2a7d4843c6278e1da44b5e1: Prepare v2021.04 (2021-04-05 11:03:29 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20210409 for you to fetch changes up to 2c2d7d6a72ba4a4f9323f24b8caa3b1e05546d83: arm: stm32mp1: Set soc_type, soc_pkg, soc_rev env variables (2021-04-09 14:45:25 +0200) ---------------------------------------------------------------- Add rt-thread art-pi board support based on STM32H750 SoC Add Engicam i.Core STM32MP1 SoM Add FIP header support for STM32programmer Update uart number when no serial device found for STM32MP1 Remove board_check_usb_power function when ADC flag is not set Update SPL size limitation for STM32MP1 Set soc_type, soc_pkg, soc_rev env variables for STM32MP1 ---------------------------------------------------------------- Alexandru Gagniuc (3): configs: stm32mp1: stm32mp1: Increase SPL malloc() size configs: stm32mp1: Remove misleading CONFIG_SPL_BSS_START_ADDR configs: stm32mp1: Fix misleading SPL size limitations Jagan Teki (8): ARM: dts: stm32: Add Engicam i.Core STM32MP1 SoM ARM: dts: stm32: Add Engicam i.Core STM32MP1 1X4Gb DDR3 ARM: stm32: Imply SPL_SPI_LOAD board: stm32: Add Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit board: stm32: Add Engicam i.Core STM32MP1 C.TOUCH 2.0 ARM: dts: stm32: Add Engicam MicroGEA STM32MP1 Micro SoM board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 board board: stm32: Add Engicam MicroGEA STM32MP1 MicroDev 2.0 7" OF Marek Vasut (1): arm: stm32mp1: Set soc_type, soc_pkg, soc_rev env variables Patrick Delaunay (4): stm32mp: stm32prog: add FIP header support stm32mp: update uart number in trace of serial device not found stm32mp: replace printf by log macro in setup_boot_mode stm32mp1: remove the board_check_usb_power function when ADC is not activated dillon min (7): ARM: dts: stm32: split sdram pin & timing parameter into specific board dts ARM: dts: stm32: introduce stm32h7-pinctrl.dtsi to support stm32h750 ARM: dts: stm32: add new instances for stm32h743 MCU ARM: dts: stm32: fix i2c node typo in stm32h743, update dmamux1 register ARM: dts: stm32: add support for art-pi board based on stm32h750xbh6 ram: stm32: fix strsep failed on read only memory board: Add rt-thread art-pi board support arch/arm/dts/Makefile | 7 +- arch/arm/dts/stm32h7-pinctrl.dtsi | 274 ++++++++++++++++++ arch/arm/dts/stm32h7-u-boot.dtsi | 100 +------ arch/arm/dts/stm32h743-pinctrl.dtsi | 306 --------------------- arch/arm/dts/stm32h743.dtsi | 178 +++++++++++- arch/arm/dts/stm32h743i-disco-u-boot.dtsi | 98 +++++++ arch/arm/dts/stm32h743i-disco.dts | 2 +- arch/arm/dts/stm32h743i-eval-u-boot.dtsi | 98 +++++++ arch/arm/dts/stm32h743i-eval.dts | 2 +- arch/arm/dts/stm32h750.dtsi | 5 + arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi | 81 ++++++ arch/arm/dts/stm32h750i-art-pi.dts | 188 +++++++++++++ .../dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi | 119 ++++++++ .../stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi | 51 ++++ .../arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts | 47 ++++ ...stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi | 51 ++++ .../dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts | 47 ++++ .../arm/dts/stm32mp157a-icore-stm32mp1-u-boot.dtsi | 146 ++++++++++ arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi | 196 +++++++++++++ ...a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi | 51 ++++ ...m32mp157a-microgea-stm32mp1-microdev2.0-of7.dts | 154 +++++++++++ ...p157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi | 51 ++++ .../stm32mp157a-microgea-stm32mp1-microdev2.0.dts | 55 ++++ .../dts/stm32mp157a-microgea-stm32mp1-u-boot.dtsi | 118 ++++++++ arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi | 148 ++++++++++ arch/arm/mach-stm32/stm32h7/Kconfig | 4 + arch/arm/mach-stm32mp/Kconfig | 56 +++- .../arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 19 +- arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 59 ++-- arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.h | 12 +- .../mach-stm32mp/cmd_stm32prog/stm32prog_serial.c | 11 +- arch/arm/mach-stm32mp/cpu.c | 115 ++++---- board/engicam/stm32mp1/Kconfig | 12 + board/engicam/stm32mp1/MAINTAINERS | 26 ++ board/engicam/stm32mp1/Makefile | 10 + board/engicam/stm32mp1/spl.c | 48 ++++ board/engicam/stm32mp1/stm32mp1.c | 125 +++++++++ board/st/stm32h750-art-pi/Kconfig | 19 ++ board/st/stm32h750-art-pi/MAINTAINERS | 7 + board/st/stm32h750-art-pi/Makefile | 6 + board/st/stm32h750-art-pi/stm32h750-art-pi.c | 58 ++++ board/st/stm32mp1/stm32mp1.c | 9 +- configs/stm32h750-art-pi_defconfig | 51 ++++ configs/stm32mp15-icore-stm32mp1-ctouch2_defconfig | 79 ++++++ .../stm32mp15-icore-stm32mp1-edimm2.2_defconfig | 79 ++++++ ...2mp15-microgea-stm32mp1-microdev2-of7_defconfig | 79 ++++++ ...stm32mp15-microgea-stm32mp1-microdev2_defconfig | 79 ++++++ drivers/ram/stm32_sdram.c | 3 + include/configs/stm32h750-art-pi.h | 48 ++++ include/configs/stm32mp1.h | 9 +- include/dt-bindings/memory/stm32-sdram.h | 2 + 51 files changed, 3085 insertions(+), 513 deletions(-) create mode 100644 arch/arm/dts/stm32h7-pinctrl.dtsi delete mode 100644 arch/arm/dts/stm32h743-pinctrl.dtsi create mode 100644 arch/arm/dts/stm32h750.dtsi create mode 100644 arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi create mode 100644 arch/arm/dts/stm32h750i-art-pi.dts create mode 100644 arch/arm/dts/stm32mp15-ddr3-icore-1x4Gb-1066-binG.dtsi create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-ctouch2.dts create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-edimm2.2.dts create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-icore-stm32mp1.dtsi create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dts create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-microdev2.0.dts create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1-u-boot.dtsi create mode 100644 arch/arm/dts/stm32mp157a-microgea-stm32mp1.dtsi create mode 100644 board/engicam/stm32mp1/Kconfig create mode 100644 board/engicam/stm32mp1/MAINTAINERS create mode 100644 board/engicam/stm32mp1/Makefile create mode 100644 board/engicam/stm32mp1/spl.c create mode 100644 board/engicam/stm32mp1/stm32mp1.c create mode 100644 board/st/stm32h750-art-pi/Kconfig create mode 100644 board/st/stm32h750-art-pi/MAINTAINERS create mode 100644 board/st/stm32h750-art-pi/Makefile create mode 100644 board/st/stm32h750-art-pi/stm32h750-art-pi.c create mode 100644 configs/stm32h750-art-pi_defconfig create mode 100644 configs/stm32mp15-icore-stm32mp1-ctouch2_defconfig create mode 100644 configs/stm32mp15-icore-stm32mp1-edimm2.2_defconfig create mode 100644 configs/stm32mp15-microgea-stm32mp1-microdev2-of7_defconfig create mode 100644 configs/stm32mp15-microgea-stm32mp1-microdev2_defconfig create mode 100644 include/configs/stm32h750-art-pi.h

2 1

[GIT PULL] SoCFPGA changes for v2021.07-rc1
by Tan, Ley Foon 10 Apr '21

10 Apr '21

Hi Tom Please pull the SoCFPGA changes for v2021.07. Regards Ley Foon The following changes since commit e9c99db7787e3b5c2ef05701177c43ed1c023c27: Merge branch '2021-04-07-CI-improvements' (2021-04-07 15:54:07 -0400) are available in the Git repository at: https://github.com/lftan/u-boot.git v2021.07-rc1 for you to fetch changes up to 96fe4f6485e92ed9da464c96c5f536698c5ee66d: arm: socfpga: smc: Add function to get usercode (2021-04-08 17:29:13 +0800) ---------------------------------------------------------------- Siew Chin Lim (11): arm: socfpga: smc: Remove unused SMC function ID arm: socfpga: Move Stratix10 and Agilex SPL common code arm: socfpga: Rename Stratix10 and Agilex handoff common macros arm: socfpga: Changed wrap_pll_config_s10.c to wrap_pll_config_soc64.c arm: socfpga: Changed system_manager_s10.c to system_manager_soc64.c arm: socfpga: Rearrange sequence of macros in handoff_soc64.h arm: socfpga: Restructure Stratix10 and Agilex handoff code arm: socfpga: Move Stratix10 and Agilex clock manager common code arm: socfpga: Changed to store QSPI reference clock in kHz arm: socfpga: Enable FIT signature with crc32 for SOC64 devices arm: socfpga: smc: Add function to get usercode arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 30 ++++++++-- arch/arm/mach-socfpga/Makefile | 14 +++-- arch/arm/mach-socfpga/clock_manager.c | 43 +++++++++++++- arch/arm/mach-socfpga/clock_manager_agilex.c | 6 -- arch/arm/mach-socfpga/clock_manager_s10.c | 8 +-- arch/arm/mach-socfpga/include/mach/clock_manager.h | 5 ++ .../include/mach/clock_manager_arria10.h | 2 - .../mach-socfpga/include/mach/clock_manager_gen5.h | 1 - .../mach-socfpga/include/mach/clock_manager_s10.h | 1 - arch/arm/mach-socfpga/include/mach/handoff_s10.h | 39 ------------- arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 62 ++++++++++++++++++++ arch/arm/mach-socfpga/include/mach/smc_api.h | 1 + .../include/mach/system_manager_soc64.h | 20 +++++-- arch/arm/mach-socfpga/mailbox_s10.c | 17 +++--- arch/arm/mach-socfpga/smc_api.c | 17 ++++++ arch/arm/mach-socfpga/spl_agilex.c | 16 ------ arch/arm/mach-socfpga/spl_s10.c | 17 ------ arch/arm/mach-socfpga/spl_soc64.c | 25 ++++++++ ...system_manager_s10.c => system_manager_soc64.c} | 55 +++++++++++------- arch/arm/mach-socfpga/wrap_handoff_soc64.c | 66 ++++++++++++++++++++++ arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 56 ------------------ ...ap_pll_config_s10.c => wrap_pll_config_soc64.c} | 16 +++--- configs/socfpga_agilex_atf_defconfig | 4 ++ configs/socfpga_agilex_vab_defconfig | 4 ++ configs/socfpga_stratix10_atf_defconfig | 4 ++ include/configs/socfpga_soc64_common.h | 4 +- include/linux/intel-smc.h | 52 +++-------------- 27 files changed, 341 insertions(+), 244 deletions(-) delete mode 100644 arch/arm/mach-socfpga/include/mach/handoff_s10.h create mode 100644 arch/arm/mach-socfpga/include/mach/handoff_soc64.h create mode 100644 arch/arm/mach-socfpga/spl_soc64.c rename arch/arm/mach-socfpga/{system_manager_s10.c => system_manager_soc64.c} (57%) create mode 100644 arch/arm/mach-socfpga/wrap_handoff_soc64.c delete mode 100644 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c rename arch/arm/mach-socfpga/{wrap_pll_config_s10.c => wrap_pll_config_soc64.c} (74%)

2 1

[PATCH] Add support for stack-protector
by Joel Peshkin 10 Apr '21

10 Apr '21

Cc: Simon Glass <sjg(a)chromium.org> Cc: Bin Meng <bmeng.cn(a)gmail.com> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Kever Yang <kever.yang(a)rock-chips.com> Cc: Heinrich Schuchardt <xypron.glpk(a)gmx.de> Cc: AKASHI Takahiro <takahiro.akashi(a)linaro.org> Cc: Usama Arif <usama.arif(a)arm.com> Cc: Sam Protsenko <joe.skb7(a)gmail.com> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Philippe Reynes <philippe.reynes(a)softathome.com> Cc: Eugeniu Rosca <roscaeugeniu(a)gmail.com> Cc: Jan Kiszka <jan.kiszka(a)siemens.com> Signed-off-by: Joel Peshkin <joel.peshkin(a)broadcom.com> --- Makefile | 4 ++++ common/Kconfig | 15 +++++++++++++++ common/Makefile | 2 ++ common/stackprot.c | 17 +++++++++++++++++ scripts/Makefile.spl | 6 ++++++ 5 files changed, 44 insertions(+) create mode 100644 common/stackprot.c diff --git a/Makefile b/Makefile index 3ee4cc00dd..6e7a81ec7d 100644 --- a/Makefile +++ b/Makefile @@ -677,7 +677,11 @@ else KBUILD_CFLAGS += -O2 endif +ifeq ($(CONFIG_STACKPROTECTOR),y) +KBUILD_CFLAGS += $(call cc-option,-fstack-protector-strong) +else KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) +endif KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks) # disable stringop warnings in gcc 8+ diff --git a/common/Kconfig b/common/Kconfig index 2bce8c9ba1..e30c3c4ab8 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -595,6 +595,21 @@ config TPL_HASH and the algorithms it supports are defined in common/hash.c. See also CMD_HASH for command-line access. +config STACKPROTECTOR + bool "Stack Protector buffer overflow detection" + default n + help + Enable stack smash detection through gcc built-in stack-protector + canary logic + +config SPL_STACKPROTECTOR + bool "Stack Protector buffer overflow detection for SPL" + default n + +config TPL_STACKPROTECTOR + bool "Stack Protector buffer overflow detection for SPL" + default n + endmenu menu "Update support" diff --git a/common/Makefile b/common/Makefile index bcf352d016..fe71e18317 100644 --- a/common/Makefile +++ b/common/Makefile @@ -138,3 +138,5 @@ obj-$(CONFIG_CMD_LOADB) += xyzModem.o obj-$(CONFIG_$(SPL_TPL_)YMODEM_SUPPORT) += xyzModem.o obj-$(CONFIG_AVB_VERIFY) += avb_verify.o +obj-$(CONFIG_$(SPL_TPL_)STACKPROTECTOR) += stackprot.o + diff --git a/common/stackprot.c b/common/stackprot.c new file mode 100644 index 0000000000..7c95b8544f --- /dev/null +++ b/common/stackprot.c @@ -0,0 +1,17 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2021 Broadcom + */ + +#include <common.h> + +DECLARE_GLOBAL_DATA_PTR; + +unsigned long __stack_chk_guard = 0xfeedf00ddeadbeef; + +void __stack_chk_fail(void) +{ + panic("Stack smashing detected in function: %p relocated from %p", + __builtin_return_address(0), + __builtin_return_address(0) - gd->reloc_off); +} diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index 9f1f7445d7..1505e4e851 100644 --- a/scripts/Makefile.spl +++ b/scripts/Makefile.spl @@ -63,6 +63,12 @@ include $(srctree)/scripts/Makefile.lib KBUILD_CFLAGS += -ffunction-sections -fdata-sections LDFLAGS_FINAL += --gc-sections +ifeq ($(CONFIG_$(SPL_TPL_)STACKPROTECTOR),y) +KBUILD_CFLAGS += -fstack-protector-strong +else +KBUILD_CFLAGS += -fno-stack-protector +endif + # FIX ME cpp_flags := $(KBUILD_CPPFLAGS) $(PLATFORM_CPPFLAGS) $(UBOOTINCLUDE) \ $(NOSTDINC_FLAGS) -- 2.27.0

4 27

Running u-boot 2021.04 on Raspberry Pi 4
by Roman Shaposhnik 10 Apr '21

10 Apr '21

Hi! first time poster, long time lurker here. Over at Project EVE https://github.com/lf-edge/eve I've been trying to migrate from our current u-boot v2020.07 + patches: https://github.com/lf-edge/eve/tree/master/pkg/u-boot/patches/patches-v2020… to the latest u-boot 2021.04. Great news is that most of the patches we dependent on seem to have been pulled upstream. However, this single *chunk* of one patchset wasn't: https://github.com/lf-edge/eve/blob/master/pkg/u-boot/patches/patches-v2020… I'm wondering what was the reason for leaving it behind, since without it I don't seem to have functioning USB devices on my Raspberry Pi 4. In fact, adding it back: https://github.com/rvs/eve/tree/u-boot/pkg/u-boot/patches/patches-v2021.04 (just that one chunk -- 'cuz the reset got upstreamed) seems to solve the issue for me. Another question I have is that the new u-boot seems to have some kind of a regression that I can't quite debug. The SMBIOS tables that it constructs during EFI boot sequence seem to be broken (see the dmidecode output below). Again, this seems to be a regression compared to v2020.07. Any ideas on what could be wrong or how can I start debugging it would be greatly appreciated (in fact I actually added printf's to write_smbios_table() to see if there's any micalculation going on -- but no -- it seems that all method->write() methods there work as expected and their cumulative output adds up to 209 bytes -- but only 128 are present) Thanks, Roman. # dmidecode Getting SMBIOS data from sysfs. SMBIOS 3.0 present. 7 structures occupying 209 bytes. Table at 0x3CB28020. Wrong DMI structures length: bytes announced, only 128 bytes available. Handle 0x0000, DMI type 0, 24 bytes BIOS Information Vendor: U-Boot Version: 2021.04 Release Date: 04/08/2021 ROM Size: 64 kB Characteristics: PCI is supported BIOS is upgradeable Selectable boot is supported I2O boot is supported Targeted content distribution is supported BIOS Revision: 21.4 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: Not Specified Product Name: Not Specified Version: Not Specified Serial Number: 100000000ffddf0b UUID: 30303031-3030-3030-3066-666464663062 Wake-up Type: Reserved SKU Number: Not Specified Family: Not Specified 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.

4 6