• State TI Thinks Resolved
  • Locked Locked
  • Replies 26 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 716 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.

AM2432: BOOT loading APP verification issue (artificially injected fault)

Jimmy
Prodigy 190 points

Part Number: AM2432

Tool/software:

Hello expert:


I am using AM2432, SDK version:mcu_plus_sdk_am243x_09_00_00_35.

According to the documentation, X509 signatures are performed during the compilation phase, and verification takes place during the boot phase. Therefore, I attempted to modify several bytes of the compiled image, appimage.hs_fs, to observe whether it would still boot successfully after burning. When I modified the first byte of appimage.hs_fs, the device failed to boot, and the boot log printed "ERROR: Bootloader_parseMultiCoreAppImage() parse image fail!!", which matched my expectation. However, when I modified the data in the middle and the last byte, the device still booted successfully after burning, which was not in line with my expectations.
My expectation is that, whether the appimage.hs_fs image is tampered with or the device's flash is damaged, the corruption should be detected during the boot-loading phase, resulting in a failed boot, but this is inconsistent with the current results. Why is this so? How does the AM2432 boot process ensure the integrity of the image?
Thank you
Jimmy
  • 0
    TI__Expert 6740 points

    Hi Meet,

    I also have a try on my side, it is same as customer. can you confirm in the function Bootloader_parseMultiCoreAppImage() we will check the whole binary integration or just check the x509 header in HSFS board? if customer want to check the whole binary, do they need change the device to hsse or they can keep using HSFS board?

    BR,

    Biao

  • 0 in reply to Biao Li
    TI__Mastermind 18090 points

    Hi Biao,

    Biao Li said:
    can you confirm in the function Bootloader_parseMultiCoreAppImage() we will check the whole binary integration or just check the x509 header in HSFS board?

    That is correct, Bootloader_parseMultiCoreAppImage only checks the x509 header and not the entire binary, that is the reason customer observes an issue when the first byte is changed but not for the others. 

    Biao Li said:
    if customer want to check the whole binary, do they need change the device to hsse or they can keep using HSFS board?

    The authentication process for HS-SE and HS-FS image is same, only x509 header is authenticated and not the entire binary, there is no need to change the device.

    Best Regards,

    Meet.

  • 0
    TI__Guru* 78261 points

    Hello,

    Jimmy said:
    My expectation is that, whether the appimage.hs_fs image is tampered with or the device's flash is damaged, the corruption should be detected during the boot-loading phase,

    This is correct expectation.

    Can you please share the image that is supposedly corrupted but still booting?

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 190 points

    Hi


    Sorry, I am unable to upload the program files here. You can try modifying an image and booting it yourself. This issue is a common occurrence, or please ask Biao to upload an image he tested.

    Thank you

    Jimmy

  • 0 in reply to Jimmy
    TI__Expert 6740 points

    Hi Prashant,

    I change last code in below image:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/ipc_5F00_notify_5F00_echo_5F00_system.release.appimage.hs_5F00_fs

    BR,

    Biao

  • 0 in reply to Biao Li
    TI__Guru* 78261 points
    Biao Li said:
    ipc_notify_echo_system.release.appimage.hs_fs

    This image is not corrupted. The SHA512 hash of the image contained in the certificate matches the SHA512 hash of the extracted appended raw appimage.

    # Expected SHA512 hash of the appended raw appimage
❯ openssl asn1parse -in ipc_notify_echo_system.release.appimage.hs_fs -inform DER -strparse 959
    0:d=0  hl=2 l=  82 cons: SEQUENCE
    2:d=1  hl=2 l=   9 prim: OBJECT            :sha512
   13:d=1  hl=2 l=  64 prim: OCTET STRING      [HEX DUMP]:7C77260DF1CEF0139E45E62E5D780D62E8CD95A62DA6A007184DBC8F5920A5A1B133729FB5245A3C8AEAFDCB33AD2EBEDE6CCE7C7A0511DB508E48FAAC082D5F
   79:d=1  hl=2 l=   3 prim: INTEGER           :01CC64
   
# Calculated SHA512 hash
❯ sha512sum ipc_notify_echo_system.release.appimage
7c77260df1cef0139e45e62e5d780d62e8cd95a62da6a007184dbc8f5920a5a1b133729fb5245a3c8aeafdcb33ad2ebede6cce7c7a0511db508e48faac082d5f  ipc_notify_echo_system.release.appimage

    Also, I do not see the modification shown in the shared image:

    ❯ xxd ipc_notify_echo_system.release.appimage.hs_fs | tail -n 10
0001d240: 0000 0000 004d 0000 0000 0000 0000 0000  .....M..........
0001d250: 0000 10e0 00e0 0f00 0000 0084 d717 0100  ................
0001d260: 0000 e803 0000 0700 0000 0200 0000 0300  ................
0001d270: 0000 0400 0000 0000 0000 0700 0000 0000  ................
0001d280: 0000 0000 0000 0000 0000 ffff ffff ffff  ................
0001d290: ffff ffff ffff ffff 0000 ffff ffff ffff  ................
0001d2a0: 0000 ffff ffff 0100 0000 0000 0000 7708  ..............w.
0001d2b0: 0300 0100 0000 0100 0000 4042 0f00 0000  ..........@B....
0001d2c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0001d2d0: 0000 ffff ffff 0000 0000                 ..........

  • 0 in reply to Prashant Shivhare
    TI__Expert 6740 points

    Hi Prashant,

    I change the last code from 00 to FF, the MD5 value will be changed:

    biao@biao:~/ti/mcu_plus_sdk_am243x_09_00_00_30/tools/boot$ md5sum ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    1b15b5ed56dcbb9aad1d6bd667f3b46f ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    biao@biao:~/ti/mcu_plus_sdk_am243x_09_00_00_30/tools/boot$ md5sum ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    378b06c5579183bb2edd1a8d2b36b7ba ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs

    I change middle code again, pls have a try below binary.

    BR,

    Biao

  • 0 in reply to Biao Li
    TI__Expert 6740 points

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/1070.ipc_5F00_notify_5F00_echo_5F00_system.release.appimage.hs_5F00_fs

  • 0 in reply to Biao Li
    TI__Expert 6740 points

    Hi Prashant,

    I also try sha512sum, it will change either I change last code or middle code.

    sha512sum ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    3bea7022f3c8dff5dcba21127aba526844343e511a0b097c1f5449018ac16d6071ca70082448cd28723c65cc65f4ea23e579272b6d96cace44d515f9716fd20d ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    biao@biao:~/ti/mcu_plus_sdk_am243x_09_00_00_30/tools/boot$ sha512sum ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs
    1bf9b3ffe3a425ab3070f1b7894a79670581cf3b43b9ac6da4361da55d8120e6c1446a083f67f74b1fb4ae95c3d9007aa0e030c1c2eb0d588cf2af3e2043ee54 ../../examples/drivers/ipc/ipc_notify_echo/am243x-lp/system_freertos_nortos/ipc_notify_echo_system.release.appimage.hs_fs

    BR,

    Biao 

  • 0 in reply to Biao Li
    TI__Guru* 78261 points
    Biao Li said:
    1070.ipc_notify_echo_system.release.appimage.hs_fs

    The authentication does fail for this image:

    [12:39:01.079] DMSC Firmware Version 9.0.7--v09.00.07 (Kool Koala)
[12:39:01.096] DMSC Firmware revision 0x9
[12:39:01.099] DMSC ABI revision 3.1

[12:39:01.110] Authentication failed!!
[12:39:01.112] Some tests have failed!!

  • 0 in reply to Prashant Shivhare
    TI__Expert 6740 points

    Hi Prashant,

    I also boot failed when change middle code. Let me double check with customer.

    BR,

    Biao

  • 0 in reply to Biao Li
    TI__Expert 6740 points

    Hi Prashant,

    customer find the reason, they disable the auth, because enable this will result boot fail.

    error log: 

    do you have any suggestion to customer?

    BR,

    Biao 

  • 0 in reply to Biao Li
    TI__Guru* 78261 points
    Biao Li said:
    do you have any suggestion to customer?

    What's the issue here? If the image is corrupted then the authentication is expected to fail.

  • 0 in reply to Prashant Shivhare
    TI__Expert 6740 points

    Hi Prashant,

    The issue is when customer enable the Auth, the normal binary will fail as well. 

    BR,

    Biao

  • 0 in reply to Biao Li
    TI__Guru* 78261 points
    Biao Li said:
    The issue is when customer enable the Auth, the normal binary will fail as well. 

    Can you please ask the customer to enable the SYSFW traces and share the same?

    Thanks!

  • 0 in reply to Prashant Shivhare
    TI__Expert 6740 points

    Hi Prashant,

    if you can share the guide of enable sysfw traces in AM24 will be better, I will let customer follow it.

    BR,

    Biao 

  • 0 in reply to Biao Li
    TI__Guru* 78261 points
    Biao Li said:
    if you can share the guide of enable sysfw traces in AM24 will be better, I will let customer follow it.

    The Sysfw logs can be enabled as follows:

    • Change "#undef SYSFW_TRACE_ENABLE" to "#define SYSFW_TRACE_ENABLE" in source/drivers/sciclient/sciclient_default_boardcfg/am64x/sciclient_defaultBoardcfg.c.
    • Build the board configurations with: make -s -C tools/sysfw/boardcfg
    • Add another UART instance in the SBL for MAIN_UART1.
    • Build the SBL.

    If the steps are followed correctly, you should see Sysfw logs on MAIN_UART1.

  • 0 in reply to Prashant Shivhare
    Prodigy 190 points
    Hello
    After following the above steps for testing, I did not see the Sysfw log output. I would like to ask: Can Sysfw log information only be output through UART1? Currently, our SBL log information is output through UART0, and my device can only connect to UART0. Also, I see in the code that UART0 is set. Why do we need to "Add another UART instance in the SBL for MAIN_UART1."?
    Thank you.
    Jimmy
  • 0 in reply to Jimmy
    TI__Guru* 78261 points
    Jimmy said:
    Can Sysfw log information only be output through UART1?

    Yes, only MAIN_UART1. There is option of reading the logs from the memory buffer as well:

    https://software-dl.ti.com/tisci/esd/latest/4_trace/trace.html#trace-memory-buffer-location

    Jimmy said:
    Also, I see in the code that UART0 is set.

    That is just a macro name. I guess it could have been named more appropriately.

    Before proceeding further with the SYSFW traces, could you please once try the latest SYSFW binaries from the SDK v11.0 and see if the authentication issue occurs.

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 190 points

    Hello

    There are a few questions I need to confirm:

    1: I made the following modifications and compiled. Is this correct?

    • Change "#undef SYSFW_TRACE_ENABLE" to "#define SYSFW_TRACE_ENABLE" in source/drivers/sciclient/sciclient_default_boardcfg/am64x/sciclient_defaultBoardcfg.c.
    • Build the board configurations with: gmake -s -C tools/sysfw/boardcfg sciclient_boardcfg SOC=am243x, this step will generate boardcfg_blob.bin and boardcfg_blob_linux.bin files in the mcu_plus_sdk_am243x_09_00_00_35/source/drivers/sciclient/sciclient_default_boardcfg/am243x directory.
    • Use gmake -C source\drivers -f makefile.am243x.r5f.ti-arm-clang all PROFILE=release DEVICE_TYPE=GP to compile drivers.am243x.r5f.ti-arm-clang.release.lib , because using gmake -s libs DEVICE=am243x results in an error as follows:

    • Recompile the SBL on CCS, generate the sbl_ospi.Debug.hs_fs.tiimage, and burn it to the device.

    2：I read the related SDK documentation, and executing gmake -s -C tools/sysfw/boardcfg sciclient_boardcfg SOC=am243x generates a hexadecimal data header file. I want to know if this hexadecimal array header file is the boardcfg_blob.bin file? How is it compiled into the lib library, and how does it take effect?

    ...

    3：Before proceeding further with the SYSFW traces, could you please once try the latest SYSFW binaries from the SDK v11.0 and see if the authentication issue occurs.

    Which specific file are the SYSFW binaries? What steps should I follow to compile them into the SBL and verify if they are working?

    Thank you.
    Jimmy
  • 0 in reply to Jimmy
    TI__Guru* 78261 points

    Hello,

    Jimmy said:
    I read the related SDK documentation, and executing gmake -s -C tools/sysfw/boardcfg sciclient_boardcfg SOC=am243x generates a hexadecimal data header file. I want to know if this hexadecimal array header file is the boardcfg_blob.bin file? How is it compiled into the lib library, and how does it take effect?

    Building the board configurations generates binary blobs and their corresponding header files. The header files are used in different context. The binary blobs are packaged with the SBL combined boot image and are consumed by the SYSFW.

    Jimmy said:
    Which specific file are the SYSFW binaries? What steps should I follow to compile them into the SBL and verify if they are working?

    The SYSFW binaries are available in the SDK folder: source/drivers/sciclient/soc/am64x_am243x/sysfw-hs*

    Replace these binaries in your SDK version with the corresponding binaries from SDK v11 and recompile the SBL.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 190 points
    Hello, after I replaced the sysfw-hs-* in mcu_plus_sdk_am243x_11_00_00_15\source\drivers\sciclient\soc\am64x_am243x, the function to verify the application image during startup is working normally. However, I noticed that the values of registers such as PLLCFG_PLL1_CTRL have changed, and they are different from the values I read when using mcu_plus_sdk_am243x_09_00_00_35. Because we have a diagnostic function, we found that after switching to the sysfw-hs-* in mcu_plus_sdk_am243x_11_00_00_15, the register read-back diagnostic function is abnormal, as shown in the registers highlighted with red boxes in the figure below;
    Why are the values of the PLLCFG_PLL1_CTRL series registers different between the sysfw-hs-* firmware in these two SDKs? What impact might this have? Since we have been using mcu_plus_sdk_am243x_09_00_00_35 for a long time, we need to clarify whether this has any impact. If I use the sysfw-hs-* firmware from mcu_plus_sdk_am243x_11_00_00_15, should the values for the PLLCFG_PLL1_CTRL registers in the register read-back diagnostic function match those in the sysfw-hs-* firmware of mcu_plus_sdk_am243x_11_00_00_15?
    Or, to put it another way, which code can I modify in mcu_plus_sdk_am243x_09_00_00_35 to recompile and regenerate the sysfw-hs-* files, resolving the boot verification issue? This way, I won't need to replace the sysfw-hs-* files in mcu_plus_sdk_am243x_11_00_00_15.
    Thank you.
    Jimmy
  • 0 in reply to Jimmy
    TI__Expert 6740 points

    Hi Prashant,

    can you help check this? it is normal or not regarding the PLLCFG_PLL1_CTRL change? can customer ignore it dirctly?

    BR,

    Biao 

  • 0 in reply to Biao Li
    TI__Guru* 78261 points

    Hello,

    Jimmy said:
    However, I noticed that the values of registers such as PLLCFG_PLL1_CTRL have changed, and they are different from the values I read when using mcu_plus_sdk_am243x_09_00_00_35.

    This might be due to the PLL sequence change in the SYSFW starting v10.0

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/11_00_00_15/exports/docs/api_guide_am64x/SYSFW_PLL_UPDATE_GUIDE.html

    The sequence is updated as a result of the Errata i2424

    https://www.ti.com/lit/er/sprz457i/sprz457i.pdf?ts=1750089199717&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FAM6442

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Expert 6740 points

    Hi Prashant,

    customer want to know can they ignore this change? using SDK9.0+sysfw10.x to SOP directly, or can you give some patch to customer, so that they can using SDK9.0+SYSFW9.0 without this issue and SOP.

    BR,

    Biao 

  • 0 in reply to Biao Li
    TI__Guru* 78261 points

    Hello,

    It is recommended to migrate to at least the SYSFW v10.0. It should be okay to use the SDK v9.0 with this SYSFW version. Just make sure to follow the instructions mentioned in the previously shared developer guide.