-----Original Message----- From: Patrick DELAUNAY [mailto:patrick.delaunay@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