SHA256 computation hangs on STM32L562 discovery board.

[GWett.1]

Hi, I hope the day is going well for everyone.

We've been working to validate SHA256 computations on the HASH unit of the board named in the question. In the process we have noted what appears to be a reproducible problem with the unit.

In short it appears as if submitting a block of data on which to compute a SHA256 checksum hangs if the block of data is an even multiple of 32 bits, the word size of register in the HASH unit.

The simplistic way to reproduce the problem is to request a hash of the following string:

abcdefghijkl

Followed by a request to compute the hash of the following string:

abcdefgh

The checksum computed from the first string is correct but the request to compute the second string hangs or gives a completely erroneous value.

We have reproduced this behavior using both the HAL_HASHEx_SHA256_Start function which uses polling mode as well as with the HAL_HASHEx_SHA256_Start_DMA function in DMA mode.

In addition to hanging on the second request in polling mode, the computation will sometimes generate a completely erroneous checksum which is notable for having long runs of null bytes in the checksum which would certainly not be expected.

In DMA mode the computation of the second digest always hangs which seems to indicate that the HASH unit is not generating a completion interrupt.

We have run multiple test vectors which give the correct checksums, a fact that seems to suggest we are using the HAL library correctly. In the case of the polling function, there doesn't seem to be much to get wrong since it simply requires calling the function with an initialized context, an input buffer and size plus an output buffer.

We have other evidence that suggests the regression occurs on various inputs when an even word size but less then a complete block size is submitted to the HASH unit.

Any reflections would be of interested.

Dr. Greg

[KnarfB]

Can you pls. give a minimal code example includig HAL_HASH_Init showing the effect. I'd try to reproduce on my L552 Nucleo board, but the following works as expected with:

HAL_HASHEx_SHA256_Start( &hhash, "abcdefghijkl", 12, outBuffer, HAL_MAX_DELAY );
HAL_HASHEx_SHA256_Start( &hhash, "abcdefgh", 8, outBuffer, HAL_MAX_DELAY );

[GWett.1]

Hi, I hope everyone had a good weekend.

Thanks for taking the time to test the code on the L552. Your indication that there were no apparent problems caused us to re-double our efforts with respect to understanding what was happening on the L562 board.

We are in the process of porting our abstraction libraries to this platform. Our SHA256 object has a function that is gated by a static variable that we use to initialize cryptography infrastructure. For example, in the case of OpenSSL, it calls EVP_add_digest(EVP_SHA256()) to setup the SHA2 hashing functions.

On STM MCU we elected to use this function to enable the HASH clocks and the DMA and interrupt infrastructure. Unfortunately in the process of doing so we had inadvertently left the default HAL_HASH_MspDeInit() function that we had copied from the example STM code in place when we had initially developed the test framework for the HASH engine. The ->reset() method in our SHA256 object, that we invoke in order to re-use a SHA256 object for additional digests, of course, calls HAL_HASH_DeInit() which invoked the callback and turned off the HASH clocks which the SHA256 object would never turn on again since the static gating variable had been set to 'true'.....:face_with_tears_of_joy:

It was the most interesting collection of non-deterministic behavior that I have seen out of a piece of hardware in a long time. We even open coded direct register I/O to the HASH engine to rule out issues with the HAL library but of course we stuck that in the ->compute_digest method of the object....:sad_but_relieved_face: :)

Thanks for taking the time to run the code snippet as it firmly convinced us that we had an issue that we were not understanding.

Best wishes for a productive remainder of the week.

Dr. Greg