• State Resolved
  • Locked Locked
  • Replies 23 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 828 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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:

AM2434: SecureBoot - appimage authentication fails - firewall configuration?

AM2434: AM2434: SecureBoot - appimage authentication fails

Mark Orkenyi
Prodigy 60 points
Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

I had an open issue (E2E AM2434: SecureBoot - appimage authentication fails - firewall configuration?), however it was not solved.

The latest recommended solution was to apply a bugfix (Fix DAC mode not enabled in ospi bootloaders). 

We did apply this bugfix; during the authentication process the direct access register is enabled, however the issue still remains: The Sciclient_procBootAuthAndStart() function returns with SystemP_FAILURE.

I also checked the Flash configuration as asked (Are you already running the flash at its maximum configurations like PHY enables, running at maximum clock, protocol 8D-8D-8D, etc.) and it's set up correctly.

As mentioned previously, I have tried to authenticate and boot the image by moving it to PSRAM, and the bootloader successfully booted it, so I can assume that the images and signatures/certificates are correct.

Could you please provide a solution for this?

Thanks, Mark

  • 0
    TI__Guru 57531 points

    Hi Mark,

    Have you tested the OSPI_FLASH_IO & OSPI_FLASH_DMA examples with your custom flash part?

    AM243x MCU+ SDK: OSPI Flash IO (ti.com)

    AM243x MCU+ SDK: OSPI Flash DMA (ti.com)

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    I tried to run these examples, in our current SDK(9.01) it doesn't even run, I tried with SDK 10.0, it at least outputs errors on the console - It hangs/stops at the driver's open function.


    The only example that runs is the ospi diag one. I exported it's output as a JSON file and used that to load a custom flash configuration in syscfg, but that did not help. We have an ISSI flash on the boards (IS25WX256) which (based on previous discussions) are not working with TI's drivers.
    That's why we wrote our own OSPI driver for this flash, with which it works correctly in every case.

    The flash and our flash driver also works in the bootloader correctly, it can find and read the certificate correctly directly from flash, however it fails at Sciclient_procBootAuthAndStart() (respParam.flags & TISCI_MSG_FLAG_ACK is not set).


    Is there any reason this ISSI flash is not supported and are you sure the flash is the cause of this flag not being set?

    Thanks,

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    The authentication is working with the flash part on the TI EVM. It is working for you also if the image is moved from flash to RAM. And you do not see the issue randomly but on every reset. All this strongly suggests that the custom flash part is causing the issue.

    Mark Orkenyi said:
    The flash and our flash driver also works in the bootloader correctly, it can find and read the certificate correctly directly from flash, however it fails at Sciclient_procBootAuthAndStart() (respParam.flags & TISCI_MSG_FLAG_ACK is not set).

    The flash driver either uses memcpy or BCDMA to read data in DAC mode while the SA2UL uses PKTDMA to read data. The SA2UL configurations by SYSFW for hash calculation might be incompatible with your custom flash part.

    Can you once please try the very latest SDK v10 to use the most recent SYSFW & see if the issue occurs? If it does, I will create a bug for the most recent SYSFW version for the team to follow next.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Thanks for the explanation!

    I've tried with SDK v10's SYSFW - copied the sysfw-hs-enc.bin and sysfw-hs-enc-cert.bin to my project to compile to bootloader with these binaries. Also did the same for the boardcfg just to be sure - but the same issue remains.

    Is there anything else to try out? Should I configure SA2UL in the bootloader for example, or everything related to Sciclient_procBootAuthAndStart() is done in the sysfw binary?

    Thanks, Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Everything is done by the SYSFW for authenticating an image. Since, the issue is seen with SYSFW v10, I will create the bug now. Could you please share the SYSFW v10 logs for me to attach in the bug ticket?

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Here's the log:

    balluff_tracelog_secureboot_failure.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Configuring trace data version to: 0x03007
    x4F80001A
    0x4380001A: Resource Management: UDMAP_TX_CH_CFG(NavSS UDMAP TX channel configuration): UDMA device ID: 26
    0x00C20201: BasePort: Unknown Action: 0x03 MSG:0x020201
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800201: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000201
    0x61C0008D: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 141 Clock ID: 0
    0x00C20201: BasePort: Unknown Action: 0x03 MSG:0x020201
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800201: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000201
    0x61C00050: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 80 Clock ID: 0
    0x00C20200: BasePort: Unknown Action: 0x03 MSG:0x020200
    0x00C20024: BasePort: Unknown Action: 0x03 MSG:0x020024
    0x61800200: Power Management: MSG_RECEIVED(TI-SCI message received): Message ID: 0x00000200
    0x61C00050: Power Management: MSG_PARAM_DEV_CLK_ID(TI-SCI message content: dev/clk-ids): Device ID: 80 Clock ID: 0
    0x62000002: Power Management: MSG_PARAM_VAL(TI-SCI message content: value): Target Value: 0x00000002
    0x62C0005B: Power Management: PD_GET(Power Domain Get): PSC ID: 0 Power domain ID: 0 PD Usage Count: 91
    0x64012000: Power Management: RETENTION_GET(Retention Get): LPSC ID: 0 Power domain ID: 4 Module Retention Count: 8192
    0x64006003: Power Management: RETENTION_GET(Retention Get): LPSC ID: 0 Power domain ID: 1 Module Retention Count: 8195
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks for submitting the bug. How's the average timeline for solving such a ticket?

    Thanks, Mark

  • 0 in reply to Mark Orkenyi
    Prodigy 60 points

    Hi Prashant,



    Any news about this issue?

    How's the average timeline for solving such a ticket?

    Thanks,

    Mark

  • 0 in reply to Mark Orkenyi
    Prodigy 60 points

    Hi Prashant,


    Could I get an update about this issue please?


    Thanks,
    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    I will follow up with the team. In the meantime, can you please integrate the following test function in your SBL & share the results?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void test_func() {
    int32_t status = SystemP_SUCCESS;
    /* Assumption: OSPI DAC mode is already enabled */
    uint32_t cert_load_addr = 0x60080000;
    uint32_t n_tests = 10000, cnt = 0;
    for(uint32_t i = 0; i < n_tests; i++) {
    status = Bootloader_socAuthImage(cert_load_addr);
    if(status == SystemP_SUCCESS) {
    cnt++;
    DebugP_log("#%d: PASS\r\n", i);
    } else {
    DebugP_log("#%d: FAIL\r\n", i);
    }
    }
    DebugP_log("#PASS: %d, #FAIL: %d", cnt, n_tests - cnt);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I tested it on TI EVM & saw no failures for 10K cases.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    [19:25:52.214] DMSC Firmware Version 10.0.8--v10.00.08 (Fiery Fox)
    [19:25:52.230] DMSC Firmware revision 0xa
    [19:25:52.230] DMSC ABI revision 4.0
    [19:25:52.262] #0: PASS
    [19:25:52.294] #1: PASS
    [19:25:52.326] #2: PASS
    [19:25:52.358] #3: PASS
    [19:25:52.390] #4: PASS
    [19:25:52.440] #5: PASS
    [19:25:52.470] #6: PASS
    [19:25:52.502] #7: PASS
    [19:25:52.534] #8: PASS
    [19:25:52.566] #9: PASS
    [19:25:52.598] #10: PASS
    ...
    [19:31:27.918] #9990: PASS
    [19:31:27.950] #9991: PASS
    [19:31:27.997] #9992: PASS
    [19:31:28.030] #9993: PASS
    [19:31:28.062] #9994: PASS
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    I ran the code you requested, however I have no access to the UART output at the moment. I hope the following screenshot is enough - of course there is 0 PASS and 10000 FAILS, as it makes no difference if the Bootloader_socAuthImage is called here or in another place.

    Do you have any other code snippets that could provide some help for this bug?

    On the EVM there is an S28HS512TGAB flash. Our is IS25WX256 from ISSI as mentioned.

    Please update us with the current status of this issue ASAP.

    Thanks, Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Two points I would like to confirm with the integrated test code:

    • The OSPI handle is taken for index 1. Assuming there is only one OSPI instance added in the Sysconfig, which should be the case, the index value would be 0. Is it not the case for you? Just want to confirm if the OSPI is really in the DAC mode.
    • The application address is the 0x60080000. Do you have your application flashed at the offset 0x80000 only?

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    As we are using our own OSPI driver - as the ISSI flash is not supported by TI's driver - the getHandle function is overwritten, so this parameter is basically discarded in our implementation. Only one OSPI driver exists. We are also not using Sysconfig anymore.
    Sorry if that caused a confusion!

    The handle is valid and correct.
    The direct access is enabled at line 768, and the following screenshot proves it: ENB_DIR_ACC_CTLR_FLD is set to 1, and on the bottom you can see through memory browser the OSPI flash contents is being readable - Our application is also flashed to the 0x60080000 address as you can see.

    (We have multiple slots in our architecture, but the default slot is the one offset with 0x80000. Could multiple application images cause problem in any way?)

    Could you maybe check if the registers shown in the image is correct? Is there any other configuration necessary apart from the DAC mode?




    Thanks,
    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Thanks for the clarification!

    It looks like the OSPI is really in the DAC mode. However, the data shown in the image at 0x80000 offset doesn't look good. The point is any valid signed application image will have the certificate at the start & it will look like this

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    ❯ xxd ./examples/hello_world/am64x-evm/r5fss0-0_nortos/ti-arm-clang/hello_world.debug.appimage.hs | head
    00000000: 3082 0653 3082 043b a003 0201 0202 1436 0..S0..;.......6
    00000010: 78e2 e897 adf5 0b66 50c4 0584 b857 cdc2 x......fP....W..
    00000020: 69ee 0b30 0d06 092a 8648 86f7 0d01 010d i..0...*.H......
    00000030: 0500 3081 9031 0b30 0906 0355 0406 1302 ..0..1.0...U....
    00000040: 5553 310b 3009 0603 5504 080c 0253 4331 US1.0...U....SC1
    00000050: 1130 0f06 0355 0407 0c08 4e65 7720 596f .0...U....New Yo
    00000060: 726b 3121 301f 0603 5504 0a0c 1854 6578 rk1!0...U....Tex
    00000070: 6173 2049 6e73 7472 756d 656e 7473 2e2c as Instruments.,
    00000080: 2049 6e63 2e31 0c30 0a06 0355 040b 0c03 Inc.1.0...U....
    00000090: 4453 5031 0f30 0d06 0355 0403 0c06 416c DSP1.0...U....Al
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Can you once check if the image is not flashed correctly or something?

    Thanks!

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Thanks for pointing this out!
    We have a header in the beginning of the image (mainly because of the slots) which is 48 bytes long. You can see that the certificate is there at 0x80048.
    However, just for testing, I have removed this header and tried again - unfortunately, same result.
    I have attached another screenshot where it fails, maybe there is something that could give a hint..


    Thanks,
    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Can you run the following example

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/10_00_00_20/exports/docs/api_guide_am243x/EXAMPLES_DRIVERS_SA2UL_SHA.html

    with the default `crypto_sha.c` replaced with the following one to validate the SA2UL compatibility with the flash part.

    7167.crypto_sha.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /*
    * Copyright (C) 2021 Texas Instruments Incorporated
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the
    * distribution.
    *
    * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    It is modified to compute the SHA512 hash of a 2KB buffer located at 0x60200000 (2MB offset in the OSPI) & compare it with the known golden SHA512 hash of the following test binary

    test.bin

    Please note the example does not do any flash initialization as it is assumed the flash is left in initialized & DAC state by the SBL.

    I tested the procedure for 25K counts & did not see any failure on the TI EVM.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    I ran the example, if you don't mind I reduced it to 2500 runs - it was also fine with 25000 just the console cleared before I could take a printscreen.

    One thing I noticed is that it only works if an application is booted beforehand. If i only flash a bootloader and then load the example via CCS, it will fail at firewall_open(). Is this expected?

    Would it be possible to do an online debug session, so it might be easier to find out the cause?

    Thanks, Mark

  • 0 in reply to Mark Orkenyi
    Prodigy 60 points

    Hi,

    Could I get an answer or update on this please?

    Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    Apologies for the lack of response here.

    I have tried everything here to check if it is caused by some SDK issue but that doesn't seem to be the case. Thank you for doing all tests till now.

    I have asked the TIFS team to have a look at the issue & help figure out the root cause & accordingly the resolution.

    I would just like to have one confirmation again.

    The authentication does pass if the image is first read from flash to RAM & then authenticated, right? But not pass if the image is authenticated directly from flash even after making sure the DAC is enabled?

    An answer of YES mostly establishes some issue with SYSFW & not SDK.

    Thanks,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    "The authentication does pass if the image is first read from flash to RAM & then authenticated, right? But not pass if the image is authenticated directly from flash even after making sure the DAC is enabled?"

    Yes, this is correct. I've tested it as detailed previously by moving the image to the PSRAM, then authentication passed and the image was booted. From the flash it does not happen (DAC is definitely enabled).

    Thanks,
    Mark

  • +1 in reply to Mark Orkenyi
    TI__Guru 57531 points

    Hi Mark,

    As the FAE might have already communicated, the authentication issue was finally reproduced on the TI EVM. I now have the SYSFW binaries that fixes the issue at least on the TI EVM.

    Please test if you still see the issue with these SYSFW binaries which I will share over private chat. Please accept the friend request I have just sent.

    Thanks,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    Glad to hear, I will test it once I have received it!
    I have added you as a friend.


    Thanks, Mark

  • 0 in reply to Prashant Shivhare
    Prodigy 60 points

    Hi Prashant,

    I can confirm the received sysfw binaries fixed our issue with authentication.

    Thanks, Mark

  • 0 in reply to Mark Orkenyi
    TI__Guru 57531 points
    Mark Orkenyi said:
    I can confirm the received sysfw binaries fixed our issue with authentication.

    Thanks for the confirmation, Mark.

    Please note the fix will not come in the next SDK release v10.1 as the SYSFW freeze already happened by the time this issue was fixed. However, you could integrate the provided SYSFW binaries as they were built on top of the freezed tag v10.1.

    Regards,

    Prashant