TDA4VM: HS-FS chip with unsigned images

Hi Joshua,

The primary bootloader images, the MCU R5 bootloader (SBL or SPL) and the TIFS binaries need to be signed. This is the case even on a GP device, these need to have a x509 certificate in front of the binaries.

There are a lot of images involved during the boot, which binaries are you talking about?

What bootloader and HLOS are you using?

regards

Suman

Hi Suman,

Thanks for the reply! Currently we use tiboot3.bin + sysfw.itb as bootloader and RTOS as HLOS on R5, and tispl + uboot as bootloader and linux as HLOS on A72.

I noticed that if we use HS-FS version, then secure boot is not enabled, so it should be fine if secondary bootloader and HLOS are not signed, right?

My understanding is that TI secure boot protects the secondary bootloader, but not for HLOS, is it correct?

Hi Joshua,

Joshua Wu said:

Thanks for the reply! Currently we use tiboot3.bin + sysfw.itb as bootloader and RTOS as HLOS on R5, and tispl + uboot as bootloader and linux as HLOS on A72.

Thanks, so you are using the Linux SPL/U-Boot as your bootloader component.

Joshua Wu said:

I noticed that if we use HS-FS version, then secure boot is not enabled, so it should be fine if secondary bootloader and HLOS are not signed, right?

TIFS binary is signed and encrypted with TI Keys on HS-FS, and this binary does go through the authenticaion & decryption process as part of the boot. Apart from that all other signed binaries are signed with Customer Keys (or ROM Degenerate Key), but a HS-FS device doesn't have the Customer keys blown.

The Linux SDKs and RTOS SDKs follow slightly different models w.r.t images for HS-FS. RTOS SBL will sign the images with ROM degenerate keys, while Linux SDKs have signed them with Customer Keys (TI Dummy Keys on SDK).

Joshua Wu said:

My understanding is that TI secure boot protects the secondary bootloader, but not for HLOS, is it correct?

Correct. That said, our U-Boot code is now written in a uniform fashion for GP, HS-FS and HS-SE devices, and the bootloader code makes a device_type detection and ignores the certificates typically associated/required with HS-SE images.

This is to allow to use signed images like one would on a final product, but continue to use them in the same fashion on a development HS-FS board.

The proper Linux boot on HS-SE devices will require you to use a signed FIT image comprising of the kernel Image and the dtb. You can continue to use unsigned Linux kernel Image and dtbs on HS-FS like they would be used on a GP device.

regards

Suman

Hello Suman,

Could you please elaborate more on signed FIT image? Is it a must for HS-SE devices? Does it mean that a signed FIT image protect kernel and dtb but not rootfs?

Thanks,

Joshua

Hi, Suman

Thanks you explanation.

This is an double check and conclusion, because I want to avoid any miss understanding.

If customer want to use HS-FS device for development without unsigned image

(1) sysfw.itb -> You must use "signed" SYS FW with TI dummy key, THIS IS ENCRYPTION BY TI, NOT CUTOMERIZED KEY, it already in SDK.

(2) tiboot3.bin -> unsigned image is ok, before customer key programming.

(3) tispl.bin -> unsigned image is ok, before customer key programming.

(4) u-boot.img -> unsigned image is ok, before customer key programming.

(5) kernel + DTB (FIT image) -> unsigned image is ok, before customer key programming.

(6) rootfs -> unsigned image is ok.

If customer want to use HS-FS device with their signed key.

(1) sysfw.itb -> You must use "signed" SYS FW with TI dummy key, THIS IS ENCRYPTION BY TI, NOT CUTOMERIZED KEY, it already in SDK.

(2) tiboot3.bin -> Need customer's signed image

(3) tispl.bin -> Need customer's signed image

(4) u-boot.img -> unsigned image is also ok, because its is uniform fashion for GP, HS-FS and HS-SE devices

(5) kernel + DTB (FIT image) -> Need customer's signed image

(6) rootfs -> unsigned image is ok. 

Thank You.

Gibbs

Hi, Suman

Thanks you replies, because I am not very familiar security device, so I need to check as detail as possible.

Some clarification,

TI Dummy Key is used as a Customer SMPK Key. The TIFS binaries get delivered as signed and encrypted by TI MPK and TI MEK, which are different. So, you shouldn't be needing to "sign" the SYSFW binary with TI Dummy Key.

IF we use HS-FS device, we must to use "signed and encrypted by TI MPK and TI MEK" TIFS binaries (sysfw.itb)
IF we use GP device, we must to use no "signed and encrypted by TI MPK and TI MEK" TIFS binaries (sysfw.itb)

Even GP or HS-FS device, both sysfw.itb provided (generated) by TI, so customer do not need to care about this binary 

tiboot3.bin image should always have a x509 Certificate. So you can use either the ROM degenerate key or the Customer Private Key on HS-FS. The Customer Private Key is needed to sign on HS-SE.

IF we use HS-FS device, we must to use tiboot3.bin with customer private Key signed.
IF we use GP device, we must to use tiboot3.bin without customer private Key signed.

Our SDK will generate signed (HS-FS) and non-signed (GP) tiboot3.bin at same time, it depends on customer already add patch "Customer Private Key" in source  code or not. default key in SDK is "TI Dummy key"

FIT image is mandatory for using on HS-SE, and usage of a FIT image for GP or HS-FS is optional

If customer plan to use HS-FS device in the future, they should try to study how to use FIT image.
even FIT image "without signed", which also can running on HS-FS device

If I say something wrong, please correct me.

Thank You Very Much

Gibbs

Hi, Suman

I am a little bit confuse this term "ROM degenerate Key", Could you give us some related information?

Ref this page,

https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/10_00_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html?highlight=sysfw%20itb

Despite FIT image discussion, Our SDK will build 3 type binary, it include GP/HS-FS/HS-SE

If customer use HS-FS device without "customer Private Key", they can direct use HS-FS binary build.

If their device already become HS-SE device with"customer Private Key", they can direct use HS-SE binary build.

That is the most simple way, Am I correct?

Thank You.

Gibbs

Hi Suman

If we need to boot an HS-FS device (either 5B or 5C silicon) using the Linux SDK, is the following understanding correct:

We can use all GP images except for the following two, which must be replaced:

 For 5B HS-FS :

1. Replace sysfw-j721e-gp-evm.itb
   ➜ with sysfw-j721e_sr1_1-hs-fs-evm.itb

2. Replace tiboot3-j721e-gp-evm.bin
   ➜ with tiboot3-j721e-sr1_1-hs-fs-evm.bin

All other images (such as tispl.bin, u-boot.img, kernel, DTB, rootfs, etc.) can remain as GP versions.

 For 5C HS-FS :

1. Replace sysfw-j721e_gp-evm.itb
   ➜ with sysfw-j721e_sr2_0-hs-fs-evm.itb

2. Replace tiboot3-j721e-gp-evm.bin
   ➜ with tiboot3-j721e-sr2_0-hs-fs-evm.bin

Again, all other images can remain as GP versions.

Please confirm:
On HS-FS devices, is it correct that the only required difference compared to GP boot is using the appropriate HS-FS tiboot3 and sysfw files, while all other images (e.g., tispl.bin, u-boot.img, kernel, DTB, rootfs) can remain identical to the GP versions?

BR

JAY

Remark For Jay

What's mean for 5B/5C,

Hi Suman 

Thanks for the detailed clarification.

We’d like to further confirm our use case, which involves transitioning from GP to HS-FS device for early board bring-up and functional validation.

Our Setup & Objective

• We already have a customer board that is validated using a GP device.

• Now, we plan to replace the GP device with a 5C HS-FS device on the same board.

• The goal is to boot the HS-FS device using the existing GP images (except sysfw and tiboot3) for early-stage functional testing.

Motivation

• At this stage, we have not yet programmed the device with Keywriter, so the device is still in HS-FS  state.

• We hope to reuse the GP images to boot and verify key hardware interfaces .

• Once functional verification is complete, we will proceed to program the device with Keywriter, effectively converting it to a  HS-FS state.

• In the final stage, we will re-test using fully signed images as per the standard secure boot flow.

Summary

Our question is whether it is acceptable for early-stage HS-FS bring-up to temporarily use GP-signed images (except tiboot3 and sysfw).

Appreciate your confirmation and guidance.

BR

JAY

Hi Jay,

Jay Sun said:

We’d like to further confirm our use case, which involves transitioning from GP to HS-FS device for early board bring-up and functional validation.

Thanks for the background.

What Linux SDK is your Customer using? U-Boot has evolved while enabling the boot-support for HS-FS and also to use YAML and BinMan for generating the sysfw.itb file.

Jay Sun said:

Once functional verification is complete, we will proceed to program the device with Keywriter, effectively converting it to a  HS-FS state.

This will convert the device to HS-SE once KeyWriter is run.

Jay Sun said:

Our question is whether it is acceptable for early-stage HS-FS bring-up to temporarily use GP-signed images (except tiboot3 and sysfw).

My recommendation would be to follow the same flow as what is being used as TI SDK, as this would be the standard recommended method. 

But I understand that you want to try this as part of your early-stage board bringup. I suggest that you open a new thread if you run into any issues, I do not have a HS-FS board to check/verify this myself.

regards

Suman