• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 170 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM64x: Question about FIT image signature

AM6442: Validating a FIT image prior to processing

David Potts
Prodigy 170 points

Other Parts Discussed in Thread: AM6442

Tool/software:

As I read the R5 SPL/A53 SPL code, the FIT image header is only checked for having a valid MAGIC field before it is processed; and once processing begins, it cannot be halted.

My use-case is trying to protect against eMMC read errors in one of the images loaded by the FIT. Everything is signature-checked now, and the configuration is signed so that there cannot be any mix-and-match security attacks - but if one of the signature-checks fail, I cannot see how to 'recover' and re-read the FIT image from a fallback sector.

I note that the imx device support wraps the entire FIT image within a certificate, which permits such a pre-load check - so is TI open to considering such a change ?

Regards,

David

PS We are using SDK 10 on the yocto scarthgap branch

  • 0
    TI__Guru 74100 points

    Hi David,
    In the current Linux SDK , each SPL/u-boot binary is individually signed and packed into FIT image, and then verified by bootrom or SYSFW/TIFS, where only SW components (binary blob, dtb…) legitimately signed would pass verification process during the extended secure boot flow anchored with HW enforced root-of-trust starting from HW reset.

    The following function is the core rountine for individaully x.509 signature verification by SYSFW/TIFS
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/mach-k3/security.c?h=11.00.10#n104

    Best,
    -Hong

  • 0 in reply to Hong Guan64
    Prodigy 170 points

    Hi Hong,

    What we are concerned about is possible boot failure if one of the signed images gets corrupted on the boot media (we are using eMMC currently).

    In this case, we believe that it is possible for the tispl load to succeed with ATF and OPTEE (for example), and then fail when it attempts to load the A53-SPL - in which case the code you show will call 'hang()', which we suspect does exactly what it says.

    What we are looking for is a way of checking the entire FIT image prior to loading the components; so that we can try an alternate location for the the tispl if the 'primary' version has been corrupted. (same process would apply to u-boot.img, of course)

    I acknowledge that an alternative strategy would be to use a watchdog timer to restart the boot process if the load does hang - but we can't find any registers in the am6442 chip that would allow us to set 'user flags' so that we could tell if there had been a restart due to the watchdog, and what state the previous boot got to. (from everything I have read on the watchdog, the only 'reason' we can see is 'warm restart', which is not particularly helpful)

    Regards,

    David

  • 0 in reply to David Potts
    TI__Guru 74100 points

    Hi David,
    Once the authentication fails from the current x.509 signature verification on individually signed binary blob, I thought it would be possible to customize the code to take the necessary action, i.e. re-load/authenticate the backup signed binary blob from the backup location.
    Best,
    -Hong