AM2634: Is it possible to insert SHA-256 or CRC32 data bytes of each core into multi-core image *.appimage?

Hi Aakash,

Is it possible to add SHA-256 and CRC32 to the binary portion, i.e. Core 1 RPRC? When the code is bootloaded from flash to ram, the header part will not be loaded to the RAM, correct? 

Thanks,

Wenkai

Hi Wenkai,

Yes, that's correct that the header is not copied in the RAM.
But your use case is a little confusing for me. If you want the hash to be copied to RAM, it has to be part of the code and if that is part of the code the resultant hash will keep changing.

Can you explain me in detail what do you intend to do ?

Best Regards,
Aakash

Hi Aakash,

How about RPRC header and section header within core RPRC portion? Are those headers not loaded into the RAM either?

I think SHA-256 and CRC32 bytes can be stored in pre-defined locations and when recalculating hash, the stored hash bytes will not be included. It's just one of the options I am considering: if the hash bytes can be loaded to some fixed location and will not be used by the application, the stored value then can be compared with run-time calculated value.

Thanks,

Wenkai

Hi Wenkai,

Are you using HS-FS device or HS-SE device ?

For HS-SE device we are planning to support Extended Secure Boot which does authenticates the image before booting - https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html

For HS-FS device we are also planning to have Image Integrity check which will store the SHA512 or maybe CRC32 for the image as the part of RPRC / multicore app image format.

If you want details for the later one, let me know. I will get you the same.

Best Regards,
Aakash

Hi Aakash,

We are going to use AM2634 - is it a HS-FS device or HS-SE device? One of our modules needs safety certification and needs SHA-256 and CRC32 verification.

Another question is: how do we know the binaries in the RAM after loaded from flash still keep data integrity? 

Thanks,

Wenkai

Hi Wenkai,

The TI devices have different lifecycles. For Production devices, we have HS-FS (basic device security) and HS-SE (enhanced device security).
Most simplest way to identify the same for AM263x are -- HS-FS devices are devices with Cortex M4 debug closed and Cortex R5F cores debug opened.
For HS-SE devices, the Cortex M4 core and Cortex R5F core both the debug are closed. The devices are by default delivered in HS-FS mdoe and then can be converted into HS-SE mode by the customer.

Also, the SBL provided by TI prints the device type . I have a HS-SE device for which the prints are as follows -

Additional input required would be to understand if its the SHA-256 and CRC32 check the mandatory for safety clarification or the criterion is any Image Integrity check for safety clarification ?

Wenkai said:

how do we know the binaries in the RAM after loaded from flash still keep data integrity? 

If the requirement is to check the data verification immediately after the copy, then calculating the hash for plain data before and after copy (in streaming mode) will help. 

If the requirement is to check the data verification throughout the run-time in certain time periods, then it has to be implemented as part of another application and repeat the same hash verification.

Thanks and Regards,
Aakash

So I assume the device on my dev board am263x-lp is HS_FS. How to convert HS-FS mode to HS-SE?

Which SBL program you used can print out device type info, like HSFS or HSSE? Do you also have the source code? BTW, I imported sbl_qspi from example but it didn't work as intended - I will open another thread for it.

I found it's really hard to calculate hash of plain binary data from .appimage file because there are so many headers inside it. When you said "in streaming mode", can you explain more in detail? 

Also after binary is loaded / copied from flash to RAM, they are not located in the addresses successively, correct? Do both "entry point" in RPRC header and "section run address" in section header correspond to RAM address?

We need to calculate the hash before & after copy, and also need to check CRC throughout the run-time periodically. 

Thanks,

Wenkai

Hi Aakash,

HS-FS devices mean all generic AM2634 chips, correct? 

Do you have more concrete timeline of when this Image Integrity Check for HS-FS devices feature will be ready for customers next year, like Q1, Q2 etc.?

Aakash Kedia said:

It is sometime next year when HSMRt for HS-FS is available

What is HSMRt anyway?

Thanks,

Wenkai

Hi Aakash,

Does TI implement run-time image integrity check (like using hash or CRC) for HS-SE devices?

In your previous response you mentioned we can convert a HS-FS device to HS-SE device. Can you advise how to do that? Is there any cost difference  between HS-FS device and HS-SE device?

Thanks,

Wenkai

Hi Wenkai,

Wenkai said:

Does TI implement run-time image integrity check (like using hash or CRC) for HS-SE devices?

TI does not implement run-time integrity check for HS-SE device OOB. But the TIFS source code is delivered and customers are free to integrate this on their own accord.

Wenkai said:

you mentioned we can convert a HS-FS device to HS-SE device. Can you advise how to do that?

When you receive the HSM care package, it has a OTP key Writer utility. Using that, you can burn the keys in the fuses. After this step, the device is considered HS-SE device.

Wenkai said:

Is there any cost difference  between HS-FS device and HS-SE device?

No, there is no associated extra cost with the same. But for better confirmation, I suggest you to reach out to TI marketing.

Best Regards,
Aakash

Hi Aakash,

A few more questions:

1. If I define a constant variable at absolute address in my application code, can I easily locate that constant in rprc file and modify its value?

2. Regarding TI's image integrity check, every time when the code binary is loaded/copied from flash to RAM, will the SHA-512 be calculated from the plain data binary in the flash and compared against previously stored SHA-512 values? Also will SHA-512 from code binary in RAM be compared with the one stored in the flash after the bootloading is completed?

3. To be clear that there will be no GP device type in the future? or just HS-FS will be default but GP is still an option?

4. What is the "Device ID" in Multi-Core Header? I noticed it is always 0x37 in my case.

Thanks,

Wenkai

Hi Wenkai,

Apologies for being late to answer this query.

Wenkai said:

Do you have more concrete timeline of when this Image Integrity Check for HS-FS devices feature will be ready for customers next year, like Q1, Q2 etc.?

We are delivering this feature for AM263x as a part of Application Note and add-on feature in 8.4.1 release which is planned for Nov-Dec timeframe this year.

This feature is also planned to be part of TIFS sometime next year in 9.x release.

Wenkai said:

If I define a constant variable at absolute address in my application code, can I easily locate that constant in rprc file and modify its value?

If you dedicate a section for this variable then you might be able to locate it in RPRC file. Also as a part of optimization RPRC merges the adjacent load sections for better performance. Try to load it at an address surrounded by NOLOAD sections.

Wenkai said:

To be clear that there will be no GP device type in the future? or just HS-FS will be default but GP is still an option?

Let me come back with this answer..  

Wenkai said:

What is the "Device ID" in Multi-Core Header? I noticed it is always 0x37 in my case.

This is the device id which is set as 55 in makefile for all the example projects which create *.appimage (Multicore App Image)

Best Regards,
Aakash

Aakash Kedia said:

Try to load it at an address surrounded by NOLOAD sections

Which means I need to modify linker.cmd to add NOLOAD sections before and after the dedicated section for that variable. If I have multiple such constant variables, I also need to use NOLOAD sections to separate them, correct? 

Wenkai said:

Regarding TI's image integrity check, every time when the code binary is loaded/copied from flash to RAM, will the SHA-512 be calculated from the plain data binary in the flash and compared against previously stored SHA-512 values? Also will SHA-512 from code binary in RAM be compared with the one stored in the flash after the bootloading is completed?

How about this question?

Thanks,

Wenkai

Hi Wenkai,

Wenkai said:

Which means I need to modify linker.cmd to add NOLOAD sections before and after the dedicated section for that variable. If I have multiple such constant variables, I also need to use NOLOAD sections to separate them, correct? 

Yes. Exactly.

Wenkai said:

How about this question?

I am still finding a better design document which explains about the same. We only have this link that explains about image integrity check certificates - Security X509 Certificate Documentation — TISCI User Guide

BR,
Aakash

Aakash Kedia said:

To be clear that there will be no GP device type in the future? or just HS-FS will be default but GP is still an option?

There won't be any GP device. Just HS-FS and HS-SE.

Hi Aakash,

As to TI's new feature image integrity check, SHA-512 will be calculated for each individual core, correct?

Thanks,

Wenkai

Hi Wenkai,

Let me check for the information.

Best Regards,
Aakash

Hi Wenkai,

The Image Integrity is performed on the *.appimage. So its always multicore image. Its up to user, if it has multiple *.rprc images or not.

Hope that helps.

Best Regards,
Aakash K

Hi Aakash,

So I assume the SHA-512 will only be calculated for the plain data of all cores, not including any headers, correct?

Thanks,

Wenkai

How will you do before and after (of loading code from flash to RAM) check if the SHA values are calculated based on the entire *.appimage including all headers?

Hi Wenkai,

I told you..   It won't be very straight forward, and that's why we don't do it by default. But it is possible.

As Hash operation is supported with streaming mode, you can calculate the hash for the headers which are present on the Flash and code/data from the RAM.

In this way, this can be verified.

Best Regards,
Aakash