Buggy CRC32 implementation of DCP on i.MXRT1052?

[zambonis]

Hi everyone,

I have the MCUXpresso IDE v11.0.0 with the latest SDK v2.6.0 for EVKB-IMXRT1050. I'm working on CRC32 check for flash firmware sanity check but I have weird results. I tested the DCP example in SDK that has a CRC32 test for DCP engine: it works as in the example but as long as you put one more char in the string to compute CRC (and adjust as well the expected result) it fails. It seems that the DCP implementation of CRC32 (maybe it is a problem of SDK API) gives correct result only with certain lenghts of data.

Maybe I'm missing somthing but have done so many tests on this that I'm quite sure there should be an error somewhere. Has anyone ever encountered this same issue?

[zambonis]

Hi Kerry,

yes, exactly! This is the function I used for testing, it is from the DCP example in SDK. As you wrote the code, the CRC32 works but if you add to 'message' a char and adjust the expected value, the check fails.

I've finally found where I read adout the zero padding. In the "Security Reference Manual for the i.MX RT1050 Processor, Rev. 1, 04/2018" at page 220, "7.3.3 Hashing" you can read about CRC32 differences from the one used in ethernet standard:

         "The logic pads the zeros to a 32-bit boundary for the trailing bytes."

In my case, knowing this limitation, I need to use a software implementation because I have to verify arbitrary length messages with CRC32 appended.

Nonetheless, it's good to know where the problem is so, where applicable, you can pad messages before verifying and get the correct results using DCP hardware acceleration.

Thanks for the help!

Have a nice day.

Simone

[kerryzhou]

Thanks a lot for your detail information.

If you have the new question in the future , welcome to create the new case.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[zambonis]

Hi Kerry,

it seems a limitation in the implementation of the CRC32 in the DCP engine: it works only on data that is multiple of 4 bytes, if it is not, it will be firstly padded with zeros. So, for example, if you compute the CRC32 of "Hello" you will actually get the CRC32 of "Hello\0\0\0".

I read this somewhere but can't remember where right now. Can you help on this?

Many thanks.

Best Regards.

Simone Zamboni

[kerryzhou]

Hi Simone Zamboni,

  Do you test the following function, and when you set message is not the multiple of 4 bytes, and you meet problems, is it right?

void TestCrc32(void)
{
    status_t status;
    size_t outLength;
    unsigned int length;
    unsigned char output[4];

    static const uint8_t message[] = "abcdbcdecdefdefgefghfghighijhijk";

    /* Expected CRC-32 for the message.
     * CRC-32 params:
     * width=32 poly=0x04c11db7 init=0xffffffff refin=false refout=false xorout=0x00000000
     * http://reveng.sourceforge.net/crc-catalogue/
     */
    static const unsigned char crc32[] = {0x7f, 0x04, 0x6a, 0xdd};

    dcp_handle_t m_handle;

    m_handle.channel    = kDCP_Channel0;
    m_handle.keySlot    = kDCP_KeySlot0;
    m_handle.swapConfig = kDCP_NoSwap;

    length    = sizeof(message) - 1;
    outLength = sizeof(output);
    memset(&output, 0, outLength);

    /************************ CRC-32 **************************/
    status = DCP_HASH(DCP, &m_handle, kDCP_Crc32, message, length, output, &outLength);
    TEST_ASSERT(kStatus_Success == status);
    TEST_ASSERT(outLength == 4u);
    TEST_ASSERT(memcmp(output, crc32, outLength) == 0);

    PRINTF("CRC-32 Test pass\r\n");
}

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[kerryzhou]

Hi Simone Zamboni ，

  Please tell me you detail modified point, and the test result, and your desired result.

  Then I will help you to check it on my side.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------