> -----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
> >> xxxxxxxx):
> >> STM32MP> load mmc 0:4 ${loadaddr} publicKeyhash.bin
> >> STM32MP> stm32key read ${loadaddr}
> >> Read KEY at 0xc2000000
> >> OTP value 24: xxxxxxxx
> >> OTP value 25: xxxxxxxx
> >> OTP value 26: xxxxxxxx
> >> OTP value 27: xxxxxxxx
> >> OTP value 28: xxxxxxxx
> >> OTP value 29: xxxxxxxx
> >> OTP value 30: xxxxxxxx
> >> OTP value 31: xxxxxxxx
> >> 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: xxxxxxxx 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 0x10000018 1 1 1 1 1 1 1 1
> >> Programming bank 0 word 0x10000018 to 0x00000001...
> >> 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), all the feature in basic boot with SPL wasn't
> > developed
> >
> > By STMicroelectronics.
> >
> >
> > Today OTP LOCK feature is a a security to avoid a 2nd write on lower
> > OTP which
> >
> > will cause an ECC error.
> >
> > So it wasn't a blocking feature, you can experiment the secure boot chain
> >
> > without locking the OTP.
> >
> >
> > Reference in code : CONFIG_ARM_SMCCC is not activated
> >
> > arch/arm/mach-stm32mp/bsec.c():: stm32mp_bsec_write_lock()
> >
> >
> > static int stm32mp_bsec_write_lock(struct udevice *dev, u32 val, u32 otp)
> > {
> > if (!IS_ENABLED(CONFIG_ARM_SMCCC) || IS_ENABLED(CONFIG_SPL_BUILD))
> > return -ENOTSUPP;
> > ....
> >
> > => without TF-A the lock feature is not (yet ?) supported
> >
> >
> > reference code in TF-A:
> >
> > drivers/st/bsec/bsec2.c::bsec_permanent_lock_otp()
> >
> >
> > Regards
> >
> > Patrick
> >
> >
>
> I will propose a patch to solve this issue soon (in few day).
Thank you for your efforts.
For now, I'll port our platform to tf-a and optee,
but I'm looking forward to a patch on the mailing list.
>
> Regards
>
>
> Patrick
>
>
Best Regards,
Johann Neuhauser
