June 2020 - U-Boot

[PATCH 0/8] efi_loader: secure boot: support intermediate certificates in signature
by AKASHI Takahiro 16 Jun '20

16 Jun '20

Summary ======= under the current implementation of secure boot merged in v2020.07-rc1, UEFI subsystem verifies a signature using certificates that are coming from signature dtabase, i.e. "db." In real world, an image is signed by a signer, but its certificate can also be signed by another CA and, if it is not self-signed, the latter will be signed by yet another CA and so on. This is called a certificate chain and any certificates in the middle of chain is called "intermediate" certificates. With this patch set applied on top of the current implementation, UEFI subsystem will get capable of verifying intermediate certificates being contained in a signature and authenticating an image in a chain of trusted certificates. Please note that we don't support RFC6131, or timestamp protocol, and so if any certificate in the chain is found in the revocation list, i.e. dbx, the image will unconditionally be disqualified from being loaded or run. Patch structure =============== Patch#1-#6: preparatory patches Patch#7: main part Patch#8: pytest Prerequisite ============ Require my patch set[1]. Those two patch sets are mutually independent in terms of functionality, but have dependencies due to code overlap. You can fetch the whole workable repository from here[2]. One patch[3] to sbsigntool must also be applied so that we wil be able to sign an image with intermediate certificates. It is required here for testing. Test ==== - The added new pytest (test_signed_intca.py) passed locally. - Travis CI passed, except the new pytest added here due to a new feature in sbsigntool as mentioned above. Misc ==== - checkpatch.pl makes several warnings against pkcs7_verify.c, but we will ignore them as it is a file imported from linux code. [1] https://lists.denx.de/pipermail/u-boot/2020-June/415476.html [2] https://git.linaro.org/people/takahiro.akashi/u-boot.git efi/secboot [3] https://groups.io/g/sbsigntools/message/23 v1 (June 9, 2020) * initial release * on top of v2020.07-rc4 AKASHI Takahiro (8): lib: rsa: export rsa_verify_with_pkey() lib: crypto: add public_key_verify_signature() lib: crypto: enable x509_check_for_self_signed() lib: crypto: import pkcs7_verify.c from linux lib: crypto: add pkcs7_digest() lib: crypto: export and enhance pkcs7_verify_one() efi_loader: signature: rework for intermediate certificates support test/py: efi_secboot: add test for intermediate certificates include/crypto/pkcs7.h | 9 +- include/crypto/public_key.h | 2 +- include/efi_loader.h | 8 +- include/u-boot/rsa.h | 3 + lib/crypto/Kconfig | 3 + lib/crypto/Makefile | 1 + lib/crypto/pkcs7_verify.c | 628 ++++++++++++++++++ lib/crypto/public_key.c | 56 +- lib/crypto/x509_cert_parser.c | 2 - lib/crypto/x509_public_key.c | 33 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_image_loader.c | 2 +- lib/efi_loader/efi_signature.c | 385 +++++------ lib/efi_loader/efi_variable.c | 5 +- lib/rsa/rsa-verify.c | 8 +- test/py/tests/test_efi_secboot/conftest.py | 138 +++- test/py/tests/test_efi_secboot/defs.py | 11 +- test/py/tests/test_efi_secboot/openssl.cnf | 48 ++ .../test_efi_secboot/test_signed_intca.py | 135 ++++ 19 files changed, 1245 insertions(+), 233 deletions(-) create mode 100644 lib/crypto/pkcs7_verify.c create mode 100644 test/py/tests/test_efi_secboot/openssl.cnf create mode 100644 test/py/tests/test_efi_secboot/test_signed_intca.py -- 2.27.0

2 13

[PATCH v2] mmc: retry CMD1 in mmc_send_op_cond() until the eMMC is ready
by haibo.chen＠nxp.com 16 Jun '20

16 Jun '20

From: Haibo Chen <haibo.chen(a)nxp.com> According to eMMC specification v5.1 section 6.4.3, we should issue CMD1 repeatedly in the idle state until the eMMC is ready even if mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC devices seems to enter the inactive mode after mmc_complete_op_cond() issued CMD0 when the eMMC device is busy. Signed-off-by: Haibo Chen <haibo.chen(a)nxp.com> --- drivers/mmc/mmc.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 85762b82e0..475f75fc64 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -662,12 +662,15 @@ static int mmc_send_op_cond_iter(struct mmc *mmc, int use_arg) static int mmc_send_op_cond(struct mmc *mmc) { int err, i; + int timeout = 1000; + uint start; /* Some cards seem to need this */ mmc_go_idle(mmc); + start = get_timer(0); /* Asking to the card its capabilities */ - for (i = 0; i < 2; i++) { + for (i = 0; ; i++) { err = mmc_send_op_cond_iter(mmc, i != 0); if (err) return err; @@ -675,6 +678,10 @@ static int mmc_send_op_cond(struct mmc *mmc) /* exit if not busy (flag seems to be inverted) */ if (mmc->ocr & OCR_BUSY) break; + + if (get_timer(start) > timeout) + return -ETIMEDOUT; + udelay(100); } mmc->op_cond_pending = 1; return 0; -- 2.17.1

2 1

[PATCH] env: Kconfig: cosmetics: update comment for SYS_RELOC_GD_ENV_ADDR
by Patrick Delaunay 15 Jun '20

15 Jun '20

Update the comment for SYS_RELOC_GD_ENV_ADDR as gd->env_addr is updated in board_r.c::initr_reloc_global_data() under the compilation flags CONFIG_SYS_RELOC_GD_ENV_ADDR Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- The current code in board_r.c is: static int initr_reloc_global_data(void) { .... #ifdef CONFIG_SYS_RELOC_GD_ENV_ADDR /* * Relocate the early env_addr pointer unless we know it is not inside * the binary. Some systems need this and for the rest, it doesn't hurt. */ gd->env_addr += gd->reloc_off; #endif ... env/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index ca7fef682b..38e7fadbb9 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -562,7 +562,7 @@ config ENV_UBI_VID_OFFSET UBI VID offset for environment. If 0, no custom VID offset is used. config SYS_RELOC_GD_ENV_ADDR - bool "Relocate gd->en_addr" + bool "Relocate gd->env_addr" help Relocate the early env_addr pointer so we know it is not inside the binary. Some systems need this and for the rest, it doesn't hurt. -- 2.17.1

2 2

[PATCH 1/1] config: qemu: increase SYS_MALLOC_F_LEN
by Heinrich Schuchardt 15 Jun '20

15 Jun '20

Several configutation options require additional memory before relocation: * CONSOLE_RECORD * LOG * RSA The current default of 0x400 is too small to encompass them all. Increase the value of SYS_MALLOC_F_LEN to 0x2000 for ARCH_QEMU. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- There is a similar patch for ARCH_SUNXI still pending: arm: sunxi: increase SYS_MALLOC_F_LEN https://lists.denx.de/pipermail/u-boot/2020-June/415227.html --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 13204e2384..798a8e4d42 100644 --- a/Kconfig +++ b/Kconfig @@ -146,7 +146,7 @@ config SYS_MALLOC_F_LEN default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \ ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \ ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \ - ARCH_LS1046A || ARCH_SUNXI) + ARCH_LS1046A || ARCH_QEMU || ARCH_SUNXI) default 0x400 help Before relocation, memory is very limited on many platforms. Still, -- 2.26.2

2 1

[PATCH] Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"
by Sean Anderson 15 Jun '20

15 Jun '20

This reverts commit 0486497e2b5f4d36fa968a1a60fea358cbf70b65. The strtoul has well-defined semantics. It is defined by the C standard and POSIX. To quote the relevant section of the man pages, > If base is zero or 16, the string may then include a "0x" prefix, and the > number will be read in base 16; otherwise, a zero base is taken as 10 > (decimal) unless the next character is '0', in which case it is taken as > 8 (octal). Keeping these semantics is important for several reasons. First, it is very surprising for standard library functions to behave differently than usual. Every other implementation of strtoul has different semantics than the implementation in U-Boot at the moment. Second, it can result in very surprising results from small changes. For example, changing the string "1f" to "20" causes the parsed value to *decrease*. Forcing use of the "0x" prefix to specify hexidecimal numbers is a feature, not a bug. Lastly, this is slightly less performant, since the entire number is parsed twice. This fixes the str_simple_strtoul test failing with test/str_ut.c:29, run_strtoul(): expect_val == val: Expected 0x44b (1099), got 0x1099ab (1087915) test/str_ut.c:46, str_simple_strtoul(): 0 == run_strtoul(uts, str2, 0, 1099, 4): Expected 0x0 (0), got 0x1 (1) Signed-off-by: Sean Anderson <seanga2(a)gmail.com> CC: Michal Simek <michal.simek(a)xilinx.com> CC: Shiril Tichkule <shirilt(a)xilinx.com> --- lib/strto.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/lib/strto.c b/lib/strto.c index 3d77115d4d..c00bb5895d 100644 --- a/lib/strto.c +++ b/lib/strto.c @@ -22,25 +22,9 @@ static const char *_parse_integer_fixup_radix(const char *s, unsigned int *base) *base = 16; else *base = 8; - } else { - int i = 0; - char var; - + } else *base = 10; - - do { - var = tolower(s[i++]); - if (var >= 'a' && var <= 'f') { - *base = 16; - break; - } - - if (!(var >= '0' && var <= '9')) - break; - } while (var); - } } - if (*base == 16 && s[0] == '0' && tolower(s[1]) == 'x') s += 2; return s; -- 2.26.2

5 7

[PATCH] trivial: Fix booot occurences
by Michal Simek 15 Jun '20

15 Jun '20

s/booot/boot/g The first ase is booot instead of boot and second u-booot instead of u-boot. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- board/freescale/p1010rdb/README.P1010RDB-PA | 2 +- cmd/mmc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/p1010rdb/README.P1010RDB-PA b/board/freescale/p1010rdb/README.P1010RDB-PA index 46c61237c727..0cb950d845e7 100644 --- a/board/freescale/p1010rdb/README.P1010RDB-PA +++ b/board/freescale/p1010rdb/README.P1010RDB-PA @@ -88,7 +88,7 @@ Note: 1 stands for 'on', 0 stands for 'off' Setting of hwconfig =================== If FlexCAN or TDM is needed, please set "fsl_p1010mux:tdm_can=can" or -"fsl_p1010mux:tdm_can=tdm" explicitly in u-booot prompt as below for example: +"fsl_p1010mux:tdm_can=tdm" explicitly in u-boot prompt as below for example: setenv hwconfig "fsl_p1010mux:tdm_can=tdm;usb1:dr_mode=host,phy_type=utmi" By default, don't set fsl_p1010mux:tdm_can, in this case, spi chip selection is set to spi-flash instead of to SLIC/TDM/DAC and tdm_can_sel is set to TDM diff --git a/cmd/mmc.c b/cmd/mmc.c index 97e5d91859c9..1c252e050282 100644 --- a/cmd/mmc.c +++ b/cmd/mmc.c @@ -1004,7 +1004,7 @@ U_BOOT_CMD( "mmc part - lists available partition on current mmc device\n" "mmc dev [dev] [part] - show or set current mmc device [partition]\n" "mmc list - lists available devices\n" - "mmc wp - power on write protect booot partitions\n" + "mmc wp - power on write protect boot partitions\n" #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING) "mmc hwpartition [args...] - does hardware partitioning\n" " arguments (sizes in 512-byte blocks):\n" -- 2.27.0

3 2

[PATCH] optee: fix copy of optee reserved-memory node
by Patrick Delaunay 15 Jun '20

15 Jun '20

From: Etienne Carriere <etienne.carriere(a)linaro.org> Fix the loop that parses FDT for a reserved memory node named "optee". Before this change, if at least one subnode was found in the reserved-memory node, the function endlessly looped since instruction continue returned back in the loop without updating variable subnode. This change fixes the issue by using a for loop. Fixes: 6ccb05eae01b ("image: fdt: copy possible optee nodes to a loaded devicetree") Signed-off-by: Etienne Carriere <etienne.carriere(a)linaro.org> Signed-off-by: Patrick Delaunay <patrick.delaunay(a)st.com> --- lib/optee/optee.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/optee/optee.c b/lib/optee/optee.c index e59b5766e7..457d4cca8a 100644 --- a/lib/optee/optee.c +++ b/lib/optee/optee.c @@ -156,8 +156,9 @@ int optee_copy_fdt_nodes(const void *old_blob, void *new_blob) /* optee inserts its memory regions as reserved-memory nodes */ nodeoffset = fdt_subnode_offset(old_blob, 0, "reserved-memory"); if (nodeoffset >= 0) { - subnode = fdt_first_subnode(old_blob, nodeoffset); - while (subnode >= 0) { + for (subnode = fdt_first_subnode(old_blob, nodeoffset); + subnode >= 0; + subnode = fdt_next_subnode(old_blob, subnode)) { const char *name = fdt_get_name(old_blob, subnode, NULL); if (!name) @@ -197,8 +198,6 @@ int optee_copy_fdt_nodes(const void *old_blob, void *new_blob) if (ret < 0) return ret; } - - subnode = fdt_next_subnode(old_blob, subnode); } } -- 2.17.1

3 2

[Pull u-boot-mmc] Please pull mmc-2020-6-15
by Peng Fan 15 Jun '20

15 Jun '20

Hi Tom, Please pull u-boot-mmc mmc-2020-6-15 ----------------------------------------------------- fsl_esdhc sdr104 and hs200 fix and error path fix fsl_esdhc workaround 3.3v io issue ca_dw_mmc cleanup asic emmc DT update. ----------------------------------------------------- CI: https://travis-ci.org/github/MrVan/u-boot/builds/698360470 Thanks, Peng. The following changes since commit 9d886fd6a0888f121cd280d11434812a386045a2: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-spi (2020-06-12 17:20:35 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-2020-6-15 for you to fetch changes up to 50a17a69be076316e4c539b75403acfabf9e4c4c: mmc: fsl_esdhc: Gracefully fail on unsupported voltage switch (2020-06-15 09:45:22 +0800) ---------------------------------------------------------------- Alex Nemirovsky (1): board: presidio-asic: update eMMC DT information Arthur Li (1): mmc: ca_dw_mmc: Misc cleanup of driver Marek Vasut (2): mmc: fsl_esdhc: Fix SDR104 and HS200 support mmc: fsl_esdhc: Gracefully fail on unsupported voltage switch Yangbo Lu (2): mmc: fsl_esdhc: read register once for card inserted status mmc: fsl_esdhc: workaround for hardware 3.3v IO reliability issue arch/arm/dts/ca-presidio-engboard.dts | 4 +--- drivers/mmc/Kconfig | 15 +++++++++++++++ drivers/mmc/ca_dw_mmc.c | 34 ++++++++++++---------------------- drivers/mmc/fsl_esdhc.c | 47 ++++++++++++++++++++++++++++++++++++++++------- drivers/mmc/fsl_esdhc_imx.c | 6 ++++-- include/fsl_esdhc.h | 2 ++ 6 files changed, 74 insertions(+), 34 deletions(-)

2 1

Re: [PATCH] arm: dts: socfpga: l2c-310 full line of zeros error @kernel boot
by Nico Becker 15 Jun '20

15 Jun '20

Am 12.06.2020 um 22:27 schrieb Dinh Nguyen: > > On 6/12/20 6:41 AM, Marek Vasut wrote: >> On 6/12/20 1:04 PM, Nico Becker wrote: >>> Am 12.06.2020 um 07:51 schrieb Nico Becker: >>>> Am 11.06.2020 um 03:51 schrieb Tan, Ley Foon: >>>>>> -----Original Message----- >>>>>> From: Dinh Nguyen <dinguyen(a)kernel.org> >>>>>> Sent: Thursday, June 11, 2020 2:55 AM >>>>>> To: Marek Vasut <marex(a)denx.de>; Nico Becker <u-boot@ic- >>>>>> automation.de>; u-boot(a)lists.denx.de >>>>>> Cc: simon.k.r.goldschmidt(a)gmail.com; Tan, Ley Foon >>>>>> <ley.foon.tan(a)intel.com> >>>>>> Subject: Re: [PATCH] arm: dts: socfpga: l2c-310 full line of zeros >>>>>> error >>>>>> @kernel boot >>>>>> >>>>>> >>>>>> >>>>>> On 6/10/20 8:23 AM, Marek Vasut wrote: >>>>>>> On 6/10/20 3:21 PM, Nico Becker wrote: >>>>>>>> Am 10.06.2020 um 15:19 schrieb Marek Vasut: >>>>>>>>> On 6/10/20 3:14 PM, Nico Becker wrote: >>>>>>>>>> if i remove the arm,shared-override option in the dts file, the >>>>>>>>>> kernel boot without an error. >>>>>>>>>> With the option the kernel boots with the following error: >>>>>>>>>> dmesg --level=err >>>>>>>>>> L2C-310: enabling full line of zeros but not enabled in Cortex-A9 >>>>>>>>>> >>>>>>>>>> i ve no idea why the parameter have an effect on that. i try >>>>>>>>>> several kernels, allays the same behavior. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi >>>>>>>>>> index eda558f2fe..c2173416c7 100644 >>>>>>>>>> --- a/arch/arm/dts/socfpga.dtsi >>>>>>>>>> +++ b/arch/arm/dts/socfpga.dtsi >>>>>>>>>> @@ -719,7 +719,6 @@ >>>>>>>>>> arm,data-latency = <2 1 1>; >>>>>>>>>> prefetch-data = <1>; >>>>>>>>>> prefetch-instr = <1>; >>>>>>>>>> - arm,shared-override; >>>>>>>>>> arm,double-linefill = <1>; >>>>>>>>>> arm,double-linefill-incr = <0>; >>>>>>>>>> arm,double-linefill-wrap = <1>; >>>>>>>>>> >>>>>>>>> Do you use latest u-boot/master or some older version ? Which one? >>>>>>>> sorry, i forget it. >>>>>>>> >>>>>>>> i use v2020.01 >>>>>>> Should be OK I think. Hmmmmm, I suspect this is another fun with the >>>>>>> ACTLR/CPACR registers, like >>>>>> 937db7188e3a5ab8f802eff9b57854189379667a . >>>>>>> Ley, any ideas ? >>>>>>> >>>>>> I just tested with >>>>>> >>>>>> 2020.07-rc4-00022-gbe79009f3b along with linux v5.7, >>>>>> >>>>>> and I no longer see the error. >>>>>> >>>>> Yes, I also just tested 2020.04 uboot and 5.4.23-lts kernel, also >>>>> didn't see this error. >>>>> What kernel version you are using? >>>>> >>>>> Regards >>>>> Ley Foon >>>> hello, >>>> i use kernel 4.14.126-rt62-ltsi. >>>> >>>> greetings >>>> >>>> >>> i try the u-boot version v2020.07-rc4 without the patch, >>> and everything seems okay, no error at boot. >>> i ve no idea why the error at boot time is gone with the 2020.07-rc4 >>> version. >>> does anyone have any idea why? >>> thanks, greetings >> You can try git bisect between the two versions to find out which patch >> caused this. >> > This is the patch that fixed it: > > commit f62782fb2999dd8109a3ffe9ee0a51e54ab034ab > Author: Ley Foon Tan <ley.foon.tan(a)intel.com> > Date: Fri Apr 17 14:45:35 2020 +0800 > > cache: l2x0: Fix write to incorrect shared-override bit > > The existing code write bit-0 for shared attribute override enable bit. > It should be bit-22 based on cache controller specification [1]. > > [1] > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0246f/DDI0246F_l2c310_r… > > Signed-off-by: Ley Foon Tan <ley.foon.tan(a)intel.com> > > Dinh > hello, thanks a lot! i try the git bisect method, i was 13 builds away. next time i check first the changelog greetings

2 1

[PATCH 0/2] omap4: panda: convert to device model
by Tero Kristo 15 Jun '20

15 Jun '20

Hi, As there is looming death to OMAP4 Panda board u-boot support, I decided to take a shot and convert it to device model myself. With these patches it boots up fine, and there are no DM_SPL conversion complaints during compile time anymore. I think USB ethernet does not work anymore with this, but its better than dropping the support for the board completely. USB itself appears working, so it should be relatively easy for someone to fix the networking support if they need it. -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 12