cancel
Showing results for 
Search instead for 
Did you mean: 

TF-A not able to load OPTEE OS images when OPTEE OS images are signed.

sbg29
Associate II

Hello,

I am currently facing an issue with TFA (2.0-stm32mp-r3 from last STM32MP15 OpenSTLinux release 20-02-19) on my STM32MP157C-DK2 board,

TF-A built with wiki defined flags:

   ARM_ARCH_MAJOR=7

   ARCH=aarch32

   PLAT=stm32mp1

   DTB_FILE_NAME=stm32mp157c-dk2.dtb

   AARCH32_SP=optee

   STM32MP_BOOT_ONLY=1

   DEBUG=1

   V=1

TF-A, OPTEE-OS and U-Boot images are signed using STM32MP_SigningTool_CLI (linux version)

Hash of public key is burned into OTP WORD 24 to 31

TF-A is not able to load OPTEE OS images when images are signed.

NOTICE:  CPU: STM32MP157CAC Rev.B
NOTICE:  Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE:  Board: MB1272 Var2 Rev.C-01
NOTICE:  Boot authentication Success
INFO:    Reset reason (0x15):
INFO:      Power-on Reset (rst_por)
INFO:    PMIC version = 0x10
INFO:    Using SDMMC
INFO:      Instance 1
INFO:    Boot used partition fsbl1
NOTICE:  BL2: v2.0-r3.0(debug):
NOTICE:  BL2: Built : 10:35:37, Mar 28 2020
INFO:    BL2: Doing platform setup
INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
INFO:    Memory size = 0x20000000 (512 MB)
INFO:    BL2 runs OP-TEE setup
INFO:    BL2: Loading image id 4
INFO:    Loading image id=4 at address 0x2ffc0000
WARNING: Failed to determine the size of the image id=4 (-12)
ERROR:   BL2: Failed to load image (-12)

If I put unsigned OPTEE OS images on MMC, there is no problem. TF-A goes on U-Boot signature verification and it works ...

NOTICE:  CPU: STM32MP157CAC Rev.B
NOTICE:  Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE:  Board: MB1272 Var2 Rev.C-01
NOTICE:  Boot authentication Success
INFO:    Reset reason (0x15):
INFO:      Power-on Reset (rst_por)
INFO:    PMIC version = 0x10
INFO:    Using SDMMC
INFO:      Instance 1
INFO:    Boot used partition fsbl1
NOTICE:  BL2: v2.0-r3.0(debug):
NOTICE:  BL2: Built : 10:35:37, Mar 28 2020
INFO:    BL2: Doing platform setup
INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
INFO:    Memory size = 0x20000000 (512 MB)
INFO:    BL2 runs OP-TEE setup
INFO:    BL2: Loading image id 4
INFO:    Loading image id=4 at address 0x2ffc0000
INFO:    STM32 Image size : 512
WARNING: Skip signature check (header option)
INFO:    Image id=4 loaded: 0x2ffc0000 - 0x2ffc0200
INFO:    OPTEE ep=0x2ffc0000
INFO:    OPTEE header info:
INFO:          magic=0x4554504f
INFO:          version=0x2
INFO:          arch=0x0
INFO:          flags=0x0
INFO:          nb_images=0x2
INFO:    BL2: Loading image id 21
INFO:    Loading image id=21 at address 0x2ffc0000
INFO:    STM32 Image size : 108968
WARNING: Skip signature check (header option)
INFO:    Image id=21 loaded: 0x2ffc0000 - 0x2ffda9a8
INFO:    BL2: Loading image id 22
INFO:    Loading image id=22 at address 0xde000000
INFO:    STM32 Image size : 163840
WARNING: Skip signature check (header option)
INFO:    Image id=22 loaded: 0xde000000 - 0xde028000
INFO:    BL2: Loading image id 5
INFO:    Loading image id=5 at address 0xc0100000
INFO:    STM32 Image size : 639777
INFO:    Check signature on Non-Full-Secured platform
INFO:    Image id=5 loaded: 0xc0100000 - 0xc019c321
NOTICE:  BL2: Booting BL32
INFO:    Entry point address = 0x2ffc0000
INFO:    SPSR = 0x1d3
I/TC: Early console on UART#4
I/TC: 
I/TC: Pager is enabled. Hashes: 1536 bytes
I/TC: Pager pool size: 88kB
I/TC: OP-TEE version: Unknown #1 jeudi 26 mars 2020, 16:13:52 (UTC+0000) arm
I/TC: Platform stm32mp1: flavor stm32mp157c - device tree stm32mp157c-dk2
I/TC: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
I/TC: UART console probed from DT (non secure)
I/TC: stm32mp HSI      (18): secure        
I/TC: stm32mp LSI      (19): secure        
I/TC: stm32mp HSE      (20): secure        
I/TC: stm32mp PLL2     (27): secure        
I/TC: stm32mp PLL2_R   (30): secure        
I/TC: Initialized
 
U-Boot 2018.11-stm32mp-r4 (Mar 27 2020 - 14:24:03 +0100)
 
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
Board: stm32mp1 in op-tee mode (st,stm32mp157c-dk2)
Board: MB1272 Var2 Rev.C-01
DRAM:  480 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
****************************************************
*        WARNING 500mA power supply detected       *
*     Current too low, use a 3A power supply!      *
****************************************************
 
NAND:  0 MiB
MMC:   STM32 SDMMC2: 0, STM32 SDMMC2: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0 

Here is the MMC partitionning information:

   PartNum  Name        Address    Size    Description

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

   1        fsbl1       0x00000022 0x200   Tf-A

   2        fsbl2       0x00000222 0x200   Tf-A

   3        ssbl        0x00000422 0x800   U-Boot

   4        teeh        0x00000C22 0x200   OP-TEE OS header image

   5        teed        0x00000E22 0x200   OP-TEE OS paged data

   6        teex        0x00001022 0x200   OP-TEE OS resident core

   7        ssbl-env    0x00001222 0x10    U-Boot env

   ...

Could anyone help ?

Kind regards,

Sebastien

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Sebastien,

you are right, I also had to change the types of the op-tee images. You can do that with the -t flag of the STM32MP_SigningTool_CLI Tool. Just run the signing tool with -h so you get the allowed types.

You just have to set the binary type to the string the signing tool gives you according to your table of your first post:

fsbl Tf-A

ssbl U-Boot

teeh OP-TEE OS header image

teed OP-TEE OS pager

teex OP-TEE OS pageable

The reason for your board not booting right now is that the hash you signed doesn't fit to the signature anymore due to you changing the binary type (and therefore part of the content the hash is calculated over). So you verified that the secure boot mechanism does not boot a images that is not signed properly :).

The hash is calculated according to https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Image_signing

View solution in original post

8 REPLIES 8
Fee
Senior

Hi,

something seems not to be right with the length bits in the stm32 header of your OP-TEE header image (should be 512 bytes normally). It doesn't look like there is something wrong with your image verification (it doesn't get to this point). So maybe you should in a first step check that your stm32 header is looking as expected.

sbg29
Associate II

Hi,

Thank you for your advice !

I have checked STM32 headers before and after executing STM32MP_SigningTool_CLI (v1.0.0)

The field "binary_type" is erased by tool. This is the issue.

binary_type (0x00000020 -> 0x00000000)

STM32 Header without signature generation in optee-header_v2.stm32 image

magic_number      = 53 54 4d 32 
image_signature   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
image_checksum    = 34 0c 00 00 
header_version    = 00 00 01 00 
image_length      = 2c 00 00 00
image_entry_point = 00 00 00 00 
reserved1         = 00 00 00 00 
load_address      = 00 00 00 00 
reserved2         = 00 00 00 00
version_number    = 00 00 00 00 
option_flags      = 01 00 00 00 
ecdsa_algorithm   = 01 00 00 00
ecdsa_public_key  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
padding           = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
binary_type       = 00 00 00 20

STM32 Header with signature generation in optee-header_v2_signed.stm32 image

magic_number      = 53 54 4d 32 
image_signature   = 5e 73 31 a8 6e c7 05 51 a6 1f 82 bb 87 87 ef 01 
                    e1 eb cb 70 73 cb 75 0e 21 b9 0f 68 46 33 fd 51
                    37 48 61 d9 de be 87 1b 9f 11 e3 59 8b f2 f4 ca 
                    79 8e f4 71 05 b4 69 a3 38 cd fb b7 dc 9d 90 8e 
image_checksum    = 34 0c 00 00
header_version    = 00 00 01 00
image_length      = 2c 00 00 00
image_entry_point = 00 00 00 00 
reserved1         = 00 00 00 00 
load_address      = 00 00 00 00 
reserved2         = 00 00 00 00
version_number    = 00 00 00 00 
option_flags      = 00 00 00 00 
ecdsa_algorithm   = 01 00 00 00 
ecdsa_public_key  = ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** 
                    ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** 
                    ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
                    ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
padding           = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
binary_type       = 00 00 00 00

I tried with offical images of package (en.FLASH-stm32mp1-openstlinux-20-02-19.tar.xz) and the behaviour is the same.

I manually changed the binary types in all TEE images. The result is that Tf-A loads signed image now but I have an other issue due to this manual change (=> Wrong checksum in function check_authentication in TF-A => This is normal).

NOTICE:  Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE:  Board: MB1272 Var2 Rev.C-01
NOTICE:  Boot authentication Success
INFO:    Reset reason (0x15):
INFO:      Power-on Reset (rst_por)
INFO:    PMIC version = 0x10
INFO:    Using SDMMC
INFO:      Instance 1
INFO:    Boot used partition fsbl1
NOTICE:  BL2: v2.0-r3.0(debug):
NOTICE:  BL2: Built : 18:32:47, Mar 28 2020
INFO:    BL2: Doing platform setup
INFO:    RAM: DDR3-1066/888 bin G 1x4Gb 533MHz v1.45
INFO:    Memory size = 0x20000000 (512 MB)
INFO:    BL2 runs OP-TEE setup
INFO:    BL2: Loading image id 4
INFO:    Loading image id=4 at address 0x2ffc0000
INFO:    STM32 Image size : 512
INFO:    Check signature on Non-Full-Secured platform
ERROR:   Authentication Failed
WARNING: Failed to load image id=4 (-22)
ERROR:   BL2: Failed to load image (-22) 

Regards,

Sebastien

Hi Sebastien,

you are right, I also had to change the types of the op-tee images. You can do that with the -t flag of the STM32MP_SigningTool_CLI Tool. Just run the signing tool with -h so you get the allowed types.

You just have to set the binary type to the string the signing tool gives you according to your table of your first post:

fsbl Tf-A

ssbl U-Boot

teeh OP-TEE OS header image

teed OP-TEE OS pager

teex OP-TEE OS pageable

The reason for your board not booting right now is that the hash you signed doesn't fit to the signature anymore due to you changing the binary type (and therefore part of the content the hash is calculated over). So you verified that the secure boot mechanism does not boot a images that is not signed properly :).

The hash is calculated according to https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Image_signing

sbg29
Associate II

Hi @Lukas Brückner​ ,

Thank you !

All is working now.

Regards,

Sebastien

Olivier GALLIEN
ST Employee

Thanks @Fee for this excellent support !

You deserve ST Kudos badge I just awarded to you !

Olivier (on behalf of all ST community supporter)

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Bernard PUEL
ST Employee

Very good! I will check to update the wiki page on that use case.

@sbg29​ , how do you get this nice output content of .stm32 header file ?

Hello Bernard,

I only read the content of STM32 header in the file (with hexdump) and mapped to stm32_header structure defined in U-boot tools.

May I do one remark for signing tool:

I think that -t option should not be necessary if binary file already contains a header. -t option should for be for file with no header.

I noticed that there is (perhaps) inconsistency between OP-TEE wiki page and firmware_type field in Signing tool (Linux version)

Extract of OP-TEE wiki page:

teeh -> ../../sdd4 (OP-TEE OS header image)

teed -> ../../sdd5 (OP-TEE OS paged data)

teex -> ../../sdd6 (OP-TEE OS resident core)

dd conv=fdatasync of=/dev/sdd4 if=<optee-os>/out/core/tee-header_v2.stm32

dd conv=fdatasync of=/dev/sdd5 if=<optee-os>/out/core/tee-pageable_v2.stm32

dd conv=fdatasync of=/dev/sdd6 if=<optee-os>/out/core/tee-pager_v2.stm32

So teeh partition contains tee-header_v2.stm32 file

So teed partition contains tee-pageable_v2.stm32 file

So teex partition contains tee-pager_v2.stm32 file

But, with tool, I have to switch firmware_type between tee-pageable_v2.stm32 and tee-pager_v2.stm32 files in order to have the correct STM32 header

./STM32MP_SigningTool_CLI -t teex -bin tee-pageable_v2.stm32 ...

./STM32MP_SigningTool_CLI -t teed -bin tee-pager_v2.stm32 ...

Could you check this, please ?

Regards,

Sebastien

Bernard PUEL
ST Employee

Thanks for your inputs Sebastien,

you are right, "-bin" parameter should not be required is these cases.