Hello, I am trying to make a secure boot for my STM32MP157F. I have generated the proper keys. Running `ext4load mmc 0:4 0xc0000000 publicKeyhash.bin` puts the key in 0xc0000000. stm32key fuse 0xc0000000 does execute. But rebooting it is gone?

[GeorgeR]

..

[GeorgeR]

'Gone' meaning the key loaded is no longer there.

[TDK]

Removing "STM32 MCUs" tag and adding "STM32 MPUs".

[Kevin HUBER]

Hello @GeorgeR​ ,

Which ecosystem are you using? Is it the 2.1?

Can you send to us the result of commands

stm32key read

After the fuse operation and before the reset.

This command read the key in OTP.

Regards,

Kevin

[GeorgeR]

Hello @Kevin HUBER​ ,

I don't know the ecosystem (how can I tell) I am using the STM32MP157F-DK2 dev kit.

Doing just

stm32key read

give me an error:

STM32MP> stm32key read
stm32key - Fuse ST Hash key
 
Usage:
stm32key read <addr>: Read the hash store at addr in memory
stm32key fuse [-y] <addr> : Fuse hash store at addr in otp

I have to give it the address 0xc0000000 (as per documentation)

STM32MP> stm32key read 0xc0000000
OTP value 24: 55555555
OTP value 25: 55555555
OTP value 26: 55555555
OTP value 27: 88887777
OTP value 28: 55555555
OTP value 29: dddd2222
OTP value 30: bbbb4444
OTP value 31: 77778888
STM32MP> ext4load mmc 0:4 0xc0000000 publicKeyhash.bin
32 bytes read in 22 ms (1000 Bytes/s)
STM32MP> stm32key read 0xc0000000
OTP value 24: 5ecdbd2e
OTP value 25: b5f46d30
OTP value 26: 79f9d9ea
OTP value 27: ec42eb89
OTP value 28: f960b54e
OTP value 29: fb4f9bba
OTP value 30: 5c8068b4
OTP value 31: 63da49f4

This is the publicKeyhash that I generated (abarring endianness)

george@george-TravelMate-P446-M:~/new-buildNoMender/sgw4-build/keys$ hexdump publicKeyhash.bin
0000000 cd5e 2ebd f4b5 306d f979 ead9 42ec 89eb
0000010 60f9 4eb5 4ffb ba9b 805c b468 da63 f449
0000020

Fusing:

STM32MP> stm32key fuse 0xc0000000
Warning: Programming fuses is an irreversible operation!
 This may brick your system.
 Use this command only if you are sure of what you are doing!
 
Really perform this fuse programming? <y/N>
y
Fuse OTP 24 : 5ecdbd2e
Fuse OTP 25 : b5f46d30
Fuse OTP 26 : 79f9d9ea
Fuse OTP 27 : ec42eb89
Fuse OTP 28 : f960b54e
Fuse OTP 29 : fb4f9bba
Fuse OTP 30 : 5c8068b4
Fuse OTP 31 : 63da49f4
STM32MP>

May or may not be related. I generated signed versions of my .bin files and .stm32 files (that are in my -trusted.tsv file) It does not burn (using STM32_Programmer_CLI) my trusted bin file, it does burn with the signed stm32 files. But this might be another issue...

Thanks for your help.

George

[Kevin HUBER]

Hello @GeorgeR​ ,

Each starter package, developer package or distribution package are related to an ecocsytem version. So you can verify your ecosystem version by looking at the u-boot version or linux version of your board.

For example, here you have the latest ecosystem releate note v3.1.0: https://wiki.st.com/stm32mpu/wiki/STM32MP15_ecosystem_release_note_-_v3.1.0

But since the command "stm32key read" doesn't work on your side without parameter, I think you are on an ecosystem v2.1.0:

https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_ecosystem_release_note_-_v2.1.0

It is important to know your ecosystem, because the wiki pages are different regarding the version that you use.

So please can you provide me your linux version:

board:~# uname -a
Linux stm32mp1 5.10.61 #1 SMP PREEMPT Thu Aug 26 12:51:21 UTC 2021 armv7l armv7l armv7l GNU/Linux

or your tf-a version that you can see in the boot traces: "NOTICE: BL2: v2.4-r2.0(debug):v2.4-dirty".

Regarding that:

May or may not be related. I generated signed versions of my .bin files and .stm32 files (that are in my -trusted.tsv file) It does not burn (using STM32_Programmer_CLI) my trusted bin file, it does burn with the signed stm32 files. But this might be another issue...

By using the default stm32 tf-a binary, you have succeeded to make persistent your publicKeyhash? Did I understand correctly?

Regards,

Kevin

[GeorgeR]

Hello @Kevin HUBER​ ,

It does look like we're back a bit

root@stm32-tree:~# uname -a
Linux stm32-tree 5.10.10 #1 SMP PREEMPT Sat Jan 23 15:04:06 UTC 2021 armv7l armv7l armv7l GNU/Linux

To answer your other question (I think),

I have used the signing tool to:

~/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32MP_SigningTool_CLI \
-bin build-openstlinuxweston-stm32-tree/tmp-glibc/deploy/images/stm32-tree/arm-trusted-firmware/tf-a-stm32mp157f-stm32-tree-mx-sdcard.stm32 \
-prvk keys/private.pem \
-pubk keys/public.pem \
-pwd temppwd \
-t fsbl 
 
~/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32MP_SigningTool_CLI \
-bin build-openstlinuxweston-stm32-tree/tmp-glibc/deploy/images/stm32-tree/fip/fip-stm32mp157f-stm32-tree-mx-trusted.bin \
-prvk keys/private.pem \
-pubk keys/public.pem \
-iv 1 \
-la 0x00000000 \
-ep 0xcf9d8 \
-pwd temppwd \
-t fsbl

This creates 'signed' files `fip/fip-stm32mp157f-stm32-tree-mx-trusted_Signed.bin` and `arm-trusted-firmware/tf-a-stm32mp157f-stm32-tree-mx-sdcard_Signed.stm32`

I then edit the trusted.tsv file to use these new files. But it does not burn using the 'Signed.bin' files (error). If I replace the 'Signed.bin' with the unsigned, it does burn the SD (with the 'Signed.stm32 files), and this boots the board.

I hope I answered the question,

Thanks,

George

[Kevin HUBER]

Hello @GeorgeR​ ,

Ok so with a linux 5.10.10 you normally have the complete ecosystem v3.0.

One more question, I just saw that this tool was updated in some U-boot version delivered. Please can I have also your U-Boot version to be sure of the behavior of the tool?

Looks like that in your boot traces

U-Boot 2020.10-stm32mp-r2 (Oct 05 2020 - 15:15:32 +0000)

Regards,

Kevin

[GeorgeR]

Hello @Kevin HUBER​ ,

Apologies for the delay. I've been out for a bit. Yes,the boot looks like your version too

U-Boot 2020.10-stm32mp-r2 (Oct 05 2020 - 15:15:32 +0000)
 
CPU: STM32MP157FAC Rev.Z
Model: STMicroelectronics STM32MP157F-DK2 Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157f-dk2)
Board: MB1272 Var4.0 Rev.C-02

Regards,

George

[Kevin HUBER]

Hello @GeorgeR​ ,

Sorry for my delay too, I will try to answer quickly now.

Since you are on "U-Boot 2020.10-stm32mp-r2", you must normally have a trace like that:

	printf("Hash key updated !\n");

After "Fuse OTP 31 : 63da49f4",

I can't understand why you don't have this trace, because if you had an error, you should have an error displayed.

Please can you go inside your developer source of U-boot and add traces in this file: arch/arm/mach-stm32mp/cmd_stm32key.c

in the function

static int fuse_hash_value(u32 addr, bool print)

We have to understand which functions exit without even showing an error traces.

----------------------

Regarding the version, so you are using the U-Boot released with the ecosystem v3.1 (U-Boot 2020.10-stm32mp-r2), but the linux released with the ecosystem v3.0 (Linux stm32-tree 5.10.10) . This is weird, but it is maybe intentional .

You have to know that the U-Boot doesn't write itself the OTP, it uses the TF-A or the OP-TEE for that.

Please what are you using to boot your board on U-Boot ? Is it the TF-A or the OP-TEE?

And to avoid some weird behaviors, please be sure to use the version of TF-A or OP-TEE released at the same time that your U-Boot "U-Boot 2020.10-stm32mp-r2". The one from openstlinux-5.10-dunfell-mp1-21-11-17

Regards,

Kevin

[Kevin HUBER]

Hello @GeorgeR​ ,

Do you have more information after my previous reply?

Regards,

Kevin

[GeorgeR]

Hello @Kevin HUBER​ 

Thank you for responding. I've been pulled off this issue for awhile. We have our new hardware and are frantically trying to get it running. That being said, I think we were doing something 'sketchy' in our previous builds. When I get back to this, you will be the next to know.

Thank you for the time and information so far.

Regards,

George