STM32MP: Can't lock PHK fuses through U-Boot cmd's "stm32key" or "fuse"

[Patrick DELAUNAY]

Hi,


On 2/14/22 12:14, Patrick DELAUNAY wrote:
> Hi Johann,
>
> 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.
>
>
> 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).

Regards


Patrick