RE: [PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
> -Original Message- > From: Marek Vasut [mailto:ma...@denx.de] > Sent: Thursday, June 30, 2022 5:20 PM > > On 6/30/22 16:19, Johann Neuhauser wrote: > > PA13 and PA14 are used for USB power control and can't be used > > to enforce fastboot or stm32prog mode by pressing a button. > > > > Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied > > results in fastboot/stm32prog always starting, because PA13/PA14 are always > > low during boot. So drop the wrong trigger gpios definitions. > > > > Signed-off-by: Johann Neuhauser > > Those GPIOs also likely make no sense on DHCOM , right ? They would only make sense on the DHCOM PDK2, since this is the only mainline baseboard with user buttons available in U-Boot. > > Reviewed-by: Marek Vasut
[PATCH] arm: dts: stm32mp1: Drop fastboot and stm32prog trigger gpios on DHCOM
PA13 and PA14 are used for USB power control and can't be used
to enforce fastboot or stm32prog mode by pressing a button.
Defining CONFIG_FASTBOOT/CONFIG_CMD_STM32PROG without this patch applied
results in fastboot/stm32prog always starting, because PA13/PA14 are always
low during boot. So drop the wrong trigger gpios definitions.
Signed-off-by: Johann Neuhauser
---
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
index d73967ac1b5d..ee747a52bb7c 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
@@ -27,8 +27,6 @@
config {
u-boot,boot-led = "heartbeat";
u-boot,error-led = "error";
- st,fastboot-gpios = < 13 GPIO_ACTIVE_LOW>;
- st,stm32prog-gpios = < 14 GPIO_ACTIVE_LOW>;
dh,som-coding-gpios = < 12 0>, < 13 0>, < 15
0>;
dh,ddr3-coding-gpios = < 6 0>, < 7 0>;
};
--
2.30.2
RE: [PATCH 1/2] stm32mp: bsec: add permanent lock write support
> -Original Message-
> From: Patrick Delaunay [mailto:patrick.delau...@foss.st.com]
> Sent: Tuesday, February 15, 2022 4:09 PM
>
> Add support of the permanent lock support in U-Boot proper
> when BSEC is not managed by secure monitor (TF-A SP_MIN or OP-TEE).
>
> This patch avoid issue with stm32key command and fuse command
> on basic boot for this missing feature of U-Boot BSEC driver.
>
> Reported-by: Johann Neuhauser
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/mach-stm32mp/bsec.c | 90 +---
> 1 file changed, 84 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
> index 27d1829501..fd6e1a3957 100644
> --- a/arch/arm/mach-stm32mp/bsec.c
> +++ b/arch/arm/mach-stm32mp/bsec.c
> @@ -18,6 +18,7 @@
> #include
>
> #define BSEC_OTP_MAX_VALUE 95
> +#define BSEC_OTP_UPPER_START 32
> #define BSEC_TIMEOUT_US1
>
> /* BSEC REGISTER OFFSET (base relative) */
> @@ -41,6 +42,7 @@
> /* BSEC_CONTROL Register */
> #define BSEC_READ 0x000
> #define BSEC_WRITE 0x100
> +#define BSEC_LOCK 0x200
>
> /* LOCK Register */
> #define OTP_LOCK_MASK 0x1F
> @@ -61,6 +63,11 @@
> */
> #define BSEC_LOCK_PROGRAM 0x04
>
> +/*
> + * OTP status: bit 0 permanent lock
> + */
> +#define BSEC_LOCK_PERM BIT(0)
> +
> /**
> * bsec_lock() - manage lock for each type SR/SP/SW
> * @address: address of bsec IP register
> @@ -284,6 +291,65 @@ static int bsec_program_otp(struct udevice *dev, long
> base, u32 val, u32 otp)
> return ret;
> }
>
> +/**
> + * bsec_permanent_lock_otp() - permanent lock of OTP in SAFMEM
> + * @dev: bsec IP device
> + * @base: base address of bsec IP
> + * @otp: otp number (0 - BSEC_OTP_MAX_VALUE)
> + * Return: 0 if no error
> + */
> +static int bsec_permanent_lock_otp(struct udevice *dev, long base, uint32_t
> otp)
> +{
> + int ret;
> + bool power_up = false;
> + u32 val, addr;
> +
> + /* check if safemem is power up */
> + if (!(readl(base + BSEC_OTP_STATUS_OFF) & BSEC_MODE_PWR_MASK)) {
> + ret = bsec_power_safmem(base, true);
> + if (ret)
> + return ret;
> +
> + power_up = true;
> + }
> +
> + /*
> +* low OTPs = 2 bits word for low OTPs, 1 bits per word for upper OTP
> +* and only 16 bits used in WRDATA
> +*/
> + if (otp < BSEC_OTP_UPPER_START) {
> + addr = otp / 8;
> + val = 0x03 << ((otp * 2) & 0xF);
> + } else {
> + addr = BSEC_OTP_UPPER_START / 8 +
> + ((otp - BSEC_OTP_UPPER_START) / 16);
> + val = 0x01 << (otp & 0xF);
> + }
> +
> + /* set value in write register*/
> + writel(val, base + BSEC_OTP_WRDATA_OFF);
> +
> + /* set BSEC_OTP_CTRL_OFF with the otp addr and lock request*/
> + writel(addr | BSEC_WRITE | BSEC_LOCK, base + BSEC_OTP_CTRL_OFF);
> +
> + /* check otp status*/
> + ret = readl_poll_timeout(base + BSEC_OTP_STATUS_OFF,
> +val, (val & BSEC_MODE_BUSY_MASK) == 0,
> +BSEC_TIMEOUT_US);
> + if (ret)
> + return ret;
> +
> + if (val & BSEC_MODE_PROGFAIL_MASK)
> + ret = -EACCES;
> + else
> + ret = bsec_check_error(base, otp);
> +
> + if (power_up)
> + bsec_power_safmem(base, false);
> +
> + return ret;
> +}
> +
> /* BSEC MISC driver ***/
> struct stm32mp_bsec_plat {
> u32 base;
> @@ -339,9 +405,14 @@ static int stm32mp_bsec_read_shadow(struct udevice *dev,
> u32 *val, u32 otp)
> static int stm32mp_bsec_read_lock(struct udevice *dev, u32 *val, u32 otp)
> {
> struct stm32mp_bsec_plat *plat = dev_get_plat(dev);
> + u32 wrlock;
>
> /* return OTP permanent write lock status */
> - *val = bsec_read_lock(plat->base + BSEC_WRLOCK_OFF, otp);
> + wrlock = bsec_read_lock(plat->base + BSEC_WRLOCK_OFF, otp);
> +
> + *val = 0;
> + if (wrlock)
> + *val = BSEC_LOCK_PERM;
>
> return 0;
> }
> @@ -377,15 +448,22 @@ static int stm32mp_bsec_write_shadow(struct udevice
> *dev, u32 val, u32 otp)
>
> static int stm32mp_bsec_write_lock(struct udevice *dev,
RE: STM32MP: Can't lock PHK fuses through U-Boot cmd's "stm32key" or "fuse"
> -Original Message-
> From: Patrick DELAUNAY [mailto:patrick.delau...@foss.st.com]
> Sent: Monday, February 14, 2022 4:21 PM
>
> Hi,
>
>
> On 2/14/22 12:14, Patrick DELAUNAY wrote:
> > Hi Johann,
> >
Hello Patrick,
> > On 2/11/22 15:02, Johann Neuhauser wrote:
> >> Hello Patrick, Patrice and other devs,
> >>
> >> I'm trying to roll out secure boot with U-Boot v2022.01 only.
> >> The boot flow should be like:
> >> BootROM -(signed STM32 image)-> U-Boot SPL -(signed fit)-> U-Boot
> >> -(signed fit)-> Linux
> >>
> >> Everything except the first part in the chain is working as expected.
> >> I've used the U-Boot cmd "stm32key" to programm the file
> >> "publicKeyhash.bin",
> >> but the command failed with: "Lock OTP 24 failed".
> >>
> >> Here are the excact commands with output (hash values are replaced by
> >> ):
> >> STM32MP> load mmc 0:4 ${loadaddr} publicKeyhash.bin
> >> STM32MP> stm32key read ${loadaddr}
> >> Read KEY at 0xc200
> >> OTP value 24:
> >> OTP value 25:
> >> OTP value 26:
> >> OTP value 27:
> >> OTP value 28:
> >> OTP value 29:
> >> OTP value 30:
> >> OTP value 31:
> >> STM32MP> stm32key fuse -y ${loadaddr}
> >> Lock OTP 24 failed
> >>
> >> A second call failed because the word 24 is already fused and not
> >> locked!
> >> STM32MP> stm32key fuse ${loadaddr}
> >> OTP HASH 24: lock : 0
> >> OTP HASH 25: 0 lock : 0
> >> OTP HASH 26: 0 lock : 0
> >> OTP HASH 27: 0 lock : 0
> >> OTP HASH 28: 0 lock : 0
> >> OTP HASH 29: 0 lock : 0
> >> OTP HASH 30: 0 lock : 0
> >> OTP HASH 31: 0 lock : 0
> >> OTP 0: closed status: 0 lock : 0
> >> Hash of key is not locked!
> >> Error: can't fuse again the OTP
> >>
> >> After this failed attempt, I tried to fuse the hash with the command
> >> "fuse", like:
> >> STM32MP> fuse prog -y 0 0x18 0x4e31bbcd
> >> STM32MP> fuse prog -y 0 0x19 0x51e827dd
> >> STM32MP> fuse prog -y 0 0x1a 0x3511f521
> >> STM32MP> fuse prog -y 0 0x1b 0xfd9c11a2
> >> STM32MP> fuse prog -y 0 0x1c 0x5b997b82
> >> STM32MP> fuse prog -y 0 0x1d 0x8150adc5
> >> STM32MP> fuse prog -y 0 0x1e 0xa9c68fa9
> >> STM32MP> fuse prog -y 0 0x1f 0x72a3ba74
> >> Which gives me a matching "stm32key read" == "stm32key read
> >> ${loadaddr}",
> >> except that the fuses aren't locked.
> >>
> >> If I wanna lock the fuses with, it always fails with "ERROR":
> >> STM32MP> fuse prog -y 0 0x1018 1 1 1 1 1 1 1 1
> >> Programming bank 0 word 0x1018 to 0x0001...
> >> ERROR
> >>
> >> According to the reference manual, chapter 4, only writes to the
> >> shadow registers aren't allowed!
> >> Do you have any clue why locking the fuses isn't possilbe either with
> >> "stm32key" or with "fuse"?
> >>
> >> The next thing is, that I can't authenticate any signed STM32 images
> >> with the non locked PHK fuses.
> >> And no, I haven't closed the device already nor have I locked/fused
> >> any other fuses.
> >> I've implemented a authentication status output inside
> >> "arch/arm/mach-stm32mp/spl.c"
> >> like in TF-A "plat/st/stm32mp1/bl2_plat_setup.c", which I'll probably
> >> mainline into U-Boot.
> >> I'm using a STM32MP157C on a DHCOM with PDK2 from DH electronics GmbH.
> >>
> >> Best regards and a nice weekend,
> >> Johann Neuhauser
> >>
> >> DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49
> >> 8662 4882 0
> >> Board of Management: Stefan Daxenberger, Helmut Henschke | HRB
> >> Traunstein 9602
> >
> >
> > You correctly use the stm32key or the stm32fuse command
> >
> > https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_secure_boot
> >
> > https://wiki.st.com/stm32mpu/wiki/How_to_update_OTP_with_U-Boot
> >
> >
> > But in fact the OTP LOCK feature is NOT supported in U-Boot basic boot.
> >
Thanks for this information, I wasn't aware of this fact.
> >
> > As OpenSTLinux only use boot with TF-A and the OTP operations are
> > managed by
> >
> > secure service (SMC),
STM32MP: Can't lock PHK fuses through U-Boot cmd's "stm32key" or "fuse"
Hello Patrick, Patrice and other devs,
I'm trying to roll out secure boot with U-Boot v2022.01 only.
The boot flow should be like:
BootROM -(signed STM32 image)-> U-Boot SPL -(signed fit)-> U-Boot -(signed
fit)-> Linux
Everything except the first part in the chain is working as expected.
I've used the U-Boot cmd "stm32key" to programm the file "publicKeyhash.bin",
but the command failed with: "Lock OTP 24 failed".
Here are the excact commands with output (hash values are replaced by ):
STM32MP> load mmc 0:4 ${loadaddr} publicKeyhash.bin
STM32MP> stm32key read ${loadaddr}
Read KEY at 0xc200
OTP value 24:
OTP value 25:
OTP value 26:
OTP value 27:
OTP value 28:
OTP value 29:
OTP value 30:
OTP value 31:
STM32MP> stm32key fuse -y ${loadaddr}
Lock OTP 24 failed
A second call failed because the word 24 is already fused and not locked!
STM32MP> stm32key fuse ${loadaddr}
OTP HASH 24: lock : 0
OTP HASH 25: 0 lock : 0
OTP HASH 26: 0 lock : 0
OTP HASH 27: 0 lock : 0
OTP HASH 28: 0 lock : 0
OTP HASH 29: 0 lock : 0
OTP HASH 30: 0 lock : 0
OTP HASH 31: 0 lock : 0
OTP 0: closed status: 0 lock : 0
Hash of key is not locked!
Error: can't fuse again the OTP
After this failed attempt, I tried to fuse the hash with the command "fuse",
like:
STM32MP> fuse prog -y 0 0x18 0x4e31bbcd
STM32MP> fuse prog -y 0 0x19 0x51e827dd
STM32MP> fuse prog -y 0 0x1a 0x3511f521
STM32MP> fuse prog -y 0 0x1b 0xfd9c11a2
STM32MP> fuse prog -y 0 0x1c 0x5b997b82
STM32MP> fuse prog -y 0 0x1d 0x8150adc5
STM32MP> fuse prog -y 0 0x1e 0xa9c68fa9
STM32MP> fuse prog -y 0 0x1f 0x72a3ba74
Which gives me a matching "stm32key read" == "stm32key read ${loadaddr}",
except that the fuses aren't locked.
If I wanna lock the fuses with, it always fails with "ERROR":
STM32MP> fuse prog -y 0 0x1018 1 1 1 1 1 1 1 1
Programming bank 0 word 0x1018 to 0x0001...
ERROR
According to the reference manual, chapter 4, only writes to the shadow
registers aren't allowed!
Do you have any clue why locking the fuses isn't possilbe either with
"stm32key" or with "fuse"?
The next thing is, that I can't authenticate any signed STM32 images with the
non locked PHK fuses.
And no, I haven't closed the device already nor have I locked/fused any other
fuses.
I've implemented a authentication status output inside
"arch/arm/mach-stm32mp/spl.c"
like in TF-A "plat/st/stm32mp1/bl2_plat_setup.c", which I'll probably mainline
into U-Boot.
I'm using a STM32MP157C on a DHCOM with PDK2 from DH electronics GmbH.
Best regards and a nice weekend,
Johann Neuhauser
DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49 8662 4882 0
Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9602
RE: Compile error with SPL_FIT_FULL_CHECK and SPL_LOAD_FIT_FULL enabled
> -Original Message- > From: Simon Glass [mailto:s...@chromium.org] > Sent: Tuesday, February 8, 2022 6:13 PM > > Hi Johann, > Hi Simon, thanks for your fast answer. > On Tue, 8 Feb 2022 at 08:44, Johann Neuhauser > wrote: > > > > Dear developers and Simon, > > > > we wanna run secure boot with U-Boot's SPL_FIT_SIGNATURE and FIT_SIGNATURE > > on our STM32MP1 boards and discovered the CVE-2021-27097. > > That is already fixed in 2021.04 so you can just use a mainline U-Boot > to avoid it. > So we don't need the FIT_FULL_CHECK config symbols to mitigate against CVE-2021-27097 andwe're save if we use anything after 2021.04? > > To mitigate this vulnerability we wanna enable SPL_LOAD_FIT_FULL and > > SPL_FIT_FULL_CHECK. > > If I compile any U-Boot SPL with the mentioned config symbols after commit > > 6f3c2d8a, it fails always with the following error message: > > > > Used defconfig: stm32mp15_dhcom_basic_defconfig (+ mentioned configs > > enabled) > > ``` > > ... > > LD spl/lib/built-in.o > > LD spl/u-boot-spl > > /usr/bin/arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function > > `fit_check_format': > > /mnt/work/dev/u-boot/common/image-fit.c:1591: undefined reference to > > `fdt_check_full' > > make[1]: *** [scripts/Makefile.spl:432: spl/u-boot-spl] Error 1 > > make: *** [Makefile:1941: spl/u-boot-spl] Error 2 > > ``` > > After diging around to find the cause, we're out of ideas. > > Does anyone have a clue why the needed function is not compiled in libfdt > > for the spl build? > > SPL_OF_LIBFDT_ASSUME_MASK is set to 0xff so this check is not enabled. > I suspect that the value of that setting should change to 0 or 1 if > the full check is enabled. > I have come across this symbol before, but I did not pay any attention to it and rather looked for the problem in Makefile's related to SPL build. Many thanks for the hint. > Regards, > Simon Best regards, Johann
Compile error with SPL_FIT_FULL_CHECK and SPL_LOAD_FIT_FULL enabled
Dear developers and Simon, we wanna run secure boot with U-Boot's SPL_FIT_SIGNATURE and FIT_SIGNATURE on our STM32MP1 boards and discovered the CVE-2021-27097. To mitigate this vulnerability we wanna enable SPL_LOAD_FIT_FULL and SPL_FIT_FULL_CHECK. If I compile any U-Boot SPL with the mentioned config symbols after commit 6f3c2d8a, it fails always with the following error message: Used defconfig: stm32mp15_dhcom_basic_defconfig (+ mentioned configs enabled) ``` ... LD spl/lib/built-in.o LD spl/u-boot-spl /usr/bin/arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function `fit_check_format': /mnt/work/dev/u-boot/common/image-fit.c:1591: undefined reference to `fdt_check_full' make[1]: *** [scripts/Makefile.spl:432: spl/u-boot-spl] Error 1 make: *** [Makefile:1941: spl/u-boot-spl] Error 2 ``` After diging around to find the cause, we're out of ideas. Does anyone have a clue why the needed function is not compiled in libfdt for the spl build? Many thanks in advance. Best regards, Johann Neuhauser DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49 8662 4882 0 Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9602
Re: [U-Boot] Can't boot my FIT image: 'Could not find configuration node'
Dear Grant,
I see there is a typo in your kernel node name.
In the image section you wrote kerne-0 and in the config section you wrote
kernel = "kernel-0";
Probably this is the issue that no config and kernel image is found.
Regards,
Johann Neuhauser
> -Ursprüngliche Nachricht-
> Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Grant
> Jurgensen
> Gesendet: Montag, 6. August 2018 19:50
> An: u-boot@lists.denx.de
> Betreff: [U-Boot] Can't boot my FIT image: 'Could not find configuration
> node'
>
> Hi,
>
> I'm using U-boot to boot an ELF image. I am easily able to load the image into
> memory and boot it with the `bootelf` command. However, I'd like to create
> a FIT image in order to make use of the convenient hashing and secure boot
> features, but I'm having trouble getting my image to boot.
>
> Here is my current `.its` file (currently as simple as possible until I get
> it to
> boot):
>
> /dts-v1/;
>
> / {
> description = "SeL4";
> #address-cells = <1>;
>
> images {
> kerne-0 {
> description = "SeL4 image";
> data = /incbin/("./test_app-image-arm-exynos5");
> type = "kernel";
> arch = "arm";
> os = "qnx";
> compression = "none";
> load = <0x4800>;
> entry = <0x4800>;
> };
> };
>
> configurations {
> default = "config-0";
> config-0 {
> description = "default config";
> kernel = "kernel-0";
> };
> };
> };
>
> By the way, my ELF image isn't actually a qnx kernel. It is a sel4 kernel,
> however "sel4" is not an option. (I can make a uImage with `mkimage -A arm
> -a 0x4800 -e 0x4800 -C none -T kernel -O qnx -d
> test_app-image-exynos5 image` and can actually boot the resulting image
> here with `bootm` no problem, so I believe using the qnx OS setting
> shouldn't be a problem.)
>
> I am then able to create the FIT image with `mkimage -f sel4.its sel4.itb`.
> I copy this image to my SD card, successfully load the fit image into memory
> (with `fatload`), but then `bootm` fails with the following message:
>
> ## Loading kernel from FIT Image at 5000 ...
> Could not find configuration node
> ERROR: can't get kernel image!
>
> I can't make sense of this error. `iminfo` recognizes my default
> configuration,
> yet `bootm` can't find the configuration node?
>
> Thanks,
> Grant
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Hello Simon,
> > Dear U-Boot devs,
> >
> > I've setup verified boot on a imx6 board and want to protect my device
> against the "mix and match" attacks mentioned in
> "doc/uImage.FIT/signature.txt".
> > That's why I have only implemented signed configurations and no signed
> images as in doc/uImage.FIT/signed-configs.its.
> > My public key in my embedded fdt has the property required = "conf";
> >
> > Booting a signed config with "bootm ${loadaddr}#conf@1" and an
> embedded public key required for configurations does work as expected and
> do fail to boot if I modify the config, image, hash, signature and so on.
> >
> > If I boot any fit image(signed and unsigned) for example with "bootm
> ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot
> every image combination without signature verification although a signature
> is enforced for a configuration.
> >
> > Is this the expected behavior?
> >
> > I thought if I had set the public key in in the embedded fdt as required for
> configurations, bootm does only boot signed configurations and no
> subimages directly...
>
> I don't think there is any restriction on that at the moment. You are
> explicitly
> asking to boot particular images rather than a config. So I suppose it would
> be
> odd if U-Boot tried to enforce a config. Are you thinking it should try to
> find a
> config that has those images in it?
No, I expected that I cannot boot sub images directly if there is a required
public key for a configuration.
After a dive into the bootm source I think this is not easily possible to
enforce this behavior.
> But why not just specify the config to bootm?
At first I wanted to use a simple boot script wrapped in a fit image (unsigned)
and
have only the needed commands enabled in U-Boot.
Now I switched to a signed U-Boot script as boot script and can be sure that
this one gets not tampered.
The only bad thing is here that the source command does only have support for
fit sub images and
I have to sign the config and the image of my system image if I had a required
certificate for images and configs.
Probably this behavior should be mentioned in the doc.
Many thanks for the clarification.
Best regards
Johann Neuhauser
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] SPL: fit signature: don´t strip off signature node and sub nodes from dtb
Patch isn´t needed anymore... Now I add simply the property "u-boot,dm-spl" to my key node in the signature node with fdtput. Thanks. Best regards Johann Neuhauser ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] SPL: fit signature: don´t strip off signature node and sub nodes from dtb
Hello, I have implemented verified boot in SPL and build my SPL image with "make EXT_DTB=/path/to/dtb/with/embedded/pub-key SPL". In the build process all nodes except chosen and config are stripped off for SPL and TPL builds. Don´t know if this is a good behavior to remove everything except the mentioned nodes... Probably there is another way to embed a precompiled dtb in the SPL image? The attached patch adds the needed signature and sub nodes for verified boot to cmd_fdtgrep in scripts/Makefile.lib. Best regards Johann Neuhauser DH electronics GmbH 0001-SPL-fit-signature-don-t-strip-off-signature-node-and.patch Description: 0001-SPL-fit-signature-don-t-strip-off-signature-node-and.patch ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Converting to SPL_OF_CONTROL
Hello Alex, have you tried to set "u-boot,spl-boot-order" in choosen node? Take a look into: doc/device-tree-bindings/chosen.txt Best regards Johann Neuhauser -Ursprüngliche Nachricht- Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Alex Kiernan Gesendet: Mittwoch, 1. August 2018 12:42 An: u-boot ; Simon Glass Betreff: [U-Boot] Converting to SPL_OF_CONTROL I've long been trying to convert our board (AM3352) to all DM, after knocking out lots of problems, I've run into one I can't seem to configure my way around, when I enable SPL_OF_CONTROL. We have MMC2 as our boot device, with no MMC1 (and hence not present in the DTB). Once we're into full U-Boot this is all okay, we get the board's MMC2 appearing as mmc0 and everything's fine. My problem's during SPL, where the boot device is MMC2, the code tries to lookup by devnum (which is 1 because it numbers from 0 at this point), which doesn't exist. I'd expected aliases to work, but we don't seem to lookup up by alias, only index, so I don't have any way that I can see of overriding it. If I make this change, then everything works (with the addition of an an alias for mmc1 = ): diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index 0b2f059570..b7544ba183 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -131,7 +131,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) } #if CONFIG_IS_ENABLED(DM_MMC) - err = uclass_get_device(UCLASS_MMC, mmc_dev, ); + err = uclass_get_device_by_seq(UCLASS_MMC, mmc_dev, ); if (!err) *mmcp = mmc_get_mmc_dev(dev); #else But that feels like a pretty fundamental change to make across every board and I've no real idea if that would even be the right thing to do, or if I should be trying to fix this some other way. -- Alex Kiernan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Verified Boot: Mix and match attack
Hello developers,
I've setup verified boot on a imx6 board and want to protect my device against
the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt".
That's why, as in doc/uImage.FIT/signed-configs.its, I have only implemented
signed configurations and no signed images.
My public key in my embedded fdt has the property required = "conf";.
Booting a signed config with "bootm ${loadaddr}#conf@1" and an embedded public
key required for configurations does work as expected and do fail to boot if I
modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) with "bootm ${loadaddr}:kernel@1 -
fdt@1" to select the subimages directly, I could boot every image combination
without signature verification.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for
configurations, bootm does only boot configurations and no subimages directly...
Regards
Johann Neuhauser
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Dear U-Boot devs,
I've setup verified boot on a imx6 board and want to protect my device against
the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt".
That's why I have only implemented signed configurations and no signed images
as in doc/uImage.FIT/signed-configs.its.
My public key in my embedded fdt has the property required = "conf";
Booting a signed config with "bootm ${loadaddr}#conf@1" and an embedded public
key required for configurations does work as expected and do fail to boot if I
modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) for example with "bootm
${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot
every image combination without signature verification although a signature is
enforced for a configuration.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for
configurations, bootm does only boot signed configurations and no subimages
directly...
Best regards
Johann Neuhauser
DH electronics GmbH
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
