CST uni_sign and u-boot esbc_validate mismatch

[ch6]

I am trying to run the esbc_validate command from the u-boot command line for an ESBC image signed with CST's uni_sign tool.

It is a T4240QDS Rev 2.0 with SDK 1.8 on bank 4.

This required a modified u-boot to add CONFIG_CMD_ESBC_VALIDATE without defining CONFIG_SECBOOT so we can first test without burning the fuses.

In the 1st attempt, u-boot returned an error of "No SG support". This is due to a check in board/freescale/common/fsl_validate.c:652 to see if sg_flag in the header is non-zero:

   if (hdr->sg_flag)  return ERROR_ESBC_CLIENT_HEADER_SG;

But in CST's uni_sign.c, the sg_flag is always set to 1.

Which one is correct for how the ISBC will process the CSF header file in a real Secure Boot scenario? Do I have the wrong set of CST or u-boot files?

In the 2nd attempt, u-boot was modified to omit the above check (no longer checking if sg_flag is non-zero). The error from u-boot is now "RSA verification failed".

So the key hash matches and u-boot is able to calculate a hash of the ESBC image, but the calculated image hash and the provided image hash from the CSF header are not matching.

For now, I have placed the images at the following memory locations for testing:

CSF header  = 0xe8b00000

ESBC image = 0xe8a00000

And the call from u-boot command line is:

esbc_validate 0xe8b00000 <key hash>

Thank you for any help!

Chris

[yipingwang]

Hello Chris,

In the real Secure Boot scenario, the command esbc_validate is used to validate Kernel uImage, dts and rootfs filesystem. The IBR(internal boot ROM) is to determine if the external secure boot code(ESBC) is valid before allowing the code to execute. ESBC with CF and CSF appended, the CF header contains legacy mode fields, the CSF header includes lengths and offset which allow the IBR to located the operands used in ESBC image validation.

Please refer to the following boot flow of secure boot.

(1) IBR code would validate the ESBC code.

(2) On successful validation, ESBC code would run, it then validates the boot script.

(3) On successful validation of boot script, commands in boot script would be executed.

(4) The boot script contains commands to validate next level images, i.e rootfs, linux uImage and device tree.

(5) Once all the images are validated, bootm command in boot script would be executed which would pass control to linux

The CSF header for u-boot is generated with the following command.

./gen_keys 1024

./uni_sign --file input_files/uni_sign/t1_t2_t4/input_uboot_nor_secure

In addition, I found an obvious error in your description.

The address 0xe8a00000 is for bootscript not ESBC boot code, but the CSF header address is for ESBC U-Boot HEADER, please make sure to deploy u-boot Image the correct address, EFF40000 is for the current bank. If you want to validate bootscript, please flash Bootscript Header at E8E00000.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[ch6]

Hi Yiping,

I will try again with the addresses that you mentioned.

Does the uni_sign executable also create and append the CF header with legacy mode fields? If not, is it needed and how is that created?

Also, other than memory locations, is the IBR validation of the ESBC different from the ESBC (u-boot) validation of the boot script or do they follow a similar process?

Thank you,

Chris

[yipingwang · Accepted solution]

Hello Chris,

CF header is not needed on PBL based platforms, PBL(ProBoot Loader) is mandatory when performing secure boot. The specific PBI commands are used in secure boot, such as the following, these PBI commands should be appended in the secure boot RCW.

T1/T2/T4/B4 NOR SECURE BOOT

#LAW for ESBC

09000c10 00000000

09000c14 c0000000

09000c18 81f0001b

# LAW for CPC/SRAM

09000d00 00000000

09000d04 bff00000

09000d08 81000013

# Scratch Registers

090e0200 c0b00000

090e0208 c0c00000

# CPC SRAM

09010100 00000000

09010104 bff00009

# CPC Configuration

09010f00 08000000

09010000 80000000

The instructions inside the Internal BootROM are called Internal Secure Boot Code(ISBC), ISBC performs the following actions in secure boot.

1. CPU 0 reads its Processor ID Register.

2. CPU 0 confirms that the Sec_Mon is in the Check state.

3. CPU 0 reads the ESBC Pointer Register, and then reads the word at the indicated address, which is the first word of the Command Sequence File Header which precedes the ESBC itself.

4. CSF parsing and public key check, if CPU 0 finds a valid CSF header, it parses the CSF header to locate the public key to be used to validate the code.

5. Signature validation - With the validated public key, CPU 0 decrypts the digital signature stored with the CSF header.

6 ESBC First Instruction Pointer check, one final check is performed by the ISBC.

If ISBC passes the ESBC validation, ESBC(u-boot) will be executed. Bootscript is a script contains u-boot commands, it is validated by ESBC(u-boot) and executed by ESBC.

For details, you could refer to "Secure Boot" section in Linux SDK document, and refer to the table "Memory map for P3/P4/P5/T1_T2_T4 platforms" in "Appendix E" for NOR Flash memory map.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------