topic Re: KL28 CAU generates inconsistent SHA256 result in Kinetis Microcontrollers

KL28 CAU generates inconsistent SHA256 result

liangliangma — Fri, 20 Oct 2017 02:10:50 GMT

We are making use of the CAU unit in KL28 to calculate the digest of the 256KB application code in flash, but the result keeps changing unless the interrupt is disabled. Is it true that the interrupt must be disable for the CAU module to run?

The code is based on the mmcau library 2.0.0 from MKL28Z512xxx7 SDK 2.2 with customized wrapper. The system runs at 8MHz with SIRC. The LPTMR0 is run with LPO and interrupts every 5ms as the time base.

Re: KL28 CAU generates inconsistent SHA256 result

jingpan — Thu, 26 Oct 2017 06:18:11 GMT

Hi,

So far as I know, interrupt will not disturb MMCAU. There must be some other error in system.

Regards

Jing

Re: KL28 CAU generates inconsistent SHA256 result

patricklewis — Wed, 06 Jun 2018 16:01:58 GMT

I am having this problem as well. I can confirm that disabling interrupts when calling into the precompiled library (cau_aes_encrypt and cau_aes_decrypt) in the mmcau_AesCrypt function of fsl_mmcau.c always gets me consistent encryption/decryption results (see the placement of DisableGlobalIRQ and EnableGlobalIRQ below). If I do not disable IRQ's during these calls, I will get intermittent encryption or decryption errors. It seems that interrupts do indeed disturb the MMCAU somehow. I am also using mmcau_2.0.0.

/* common function for AES process. "encrypt" argument selects between en-/de-cryption */
static status_t mmcau_AesCrypt(const uint8_t *in, const uint8_t *keySch, uint32_t aesRounds, uint8_t *out, bool encrypt)
{
 status_t status;
/* check validity of input arguments */
 if (((aesRounds != 10u) && (aesRounds != 12u) && (aesRounds != 14u)) || (NULL == in) || (NULL == out) ||
 (NULL == keySch))
 {
 status = kStatus_InvalidArgument;
 }
 else
 {
 uint8_t inAlign[MMCAU_AES_BLOCK_SIZE]; /* 16 bytes aligned input block */
 uint8_t outAlign[MMCAU_AES_BLOCK_SIZE]; /* 16 bytes aligned output block */
 uint32_t keySchAlign[60]; /* max 60 longwords in case of 32 bytes AES key */
 size_t keySchSize = 0;
 const uint8_t *keySchWork;
 const uint8_t *inWork;
 uint8_t *outWork;
 bool copyOut;
/* compute keySchSize in bytes per CAU API documentation */
 if (aesRounds == 10u)
 {
 keySchSize = 44u;
 }
 else if (aesRounds == 12u)
 {
 keySchSize = 52u;
 }
 else /* aesRounds = 14u */
 {
 keySchSize = 60u;
 }
/* align pointers */
 inWork = mmcau_align_const(in, inAlign, MMCAU_AES_BLOCK_SIZE);
 keySchWork = mmcau_align_const(keySch, keySchAlign, keySchSize);
 outWork = mmcau_align(out, outAlign, &copyOut);
/* call actual CAU API */
 uint32_t primask = DisableGlobalIRQ();
 if (encrypt)
 {
 cau_aes_encrypt(inWork, keySchWork, aesRounds, outWork);
 }
 else
 {
 cau_aes_decrypt(inWork, keySchWork, aesRounds, outWork);
 }
 EnableGlobalIRQ(primask);
 /* copy to unaligned out pointer */
 if (copyOut)
 {
 mmcau_memcpy(out, outAlign, MMCAU_AES_BLOCK_SIZE);
 }
status = kStatus_Success;
 }
 return status;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Re: KL28 CAU generates inconsistent SHA256 result

jingpan — Fri, 09 Apr 2021 07:28:54 GMT

Hi,

Yes, you are right. It is because MMCAU lib uses a lot of multi-words LDM/STM like instructions which are abandoned by core processor (M0+) when interrupted by an interrupt and restarted execution after the interrupt is serviced. This will cause repeated write/read to the same MMCAU memory-mapped address, resulting in the wrong MMCAU operands.

This is excepted from ARM Cortex-M0+ technical document:

When an interrupt occurs during the execution of an LDM or STM instruction, the processor abandons the load multiple or store multiple operation, and the multiply instruction (if 32-cycle multiplier is used). After servicing the interrupt, the processor restarts execution of the load multiple or store multiple instruction from the beginning. The TRM has additional information about this, link below:

https://developer.arm.com/documentation/ddi0484/c/Programmers-Model/Exceptions/Exception-handling

Currently a possible workaround is to disable the interrupt before any call to MMCAU API and then re-enable it after the call.

For Cortex-M4 based MCU, it seems no such MMCAU issue as it has different implementation as it will continue executing the interrupted transaction instead of restart execution of the multi-word instruction.

Regards,

Jing