X-CUBE-CRYPTOLIB, is it thread safe when using HW crypto accelerators?

[cipher]

Posted on January 05, 2016 at 08:15

Just noticed this library called X-Cube-Cryptolib.

Quick question is , if i use the HW accelerated version of the lib, is it safe to make calls to the library from different RTOS threads considering they will be calling the crypto or hash functions that use the same peripheral, or should locking be implemented on thread level? #crypto #stm32 #cube #cubemx

[cipher]

Posted on January 23, 2016 at 19:00

Any information from ST one this topic? We really want to use STM32 HW Crypto peripherals, however we need to know how to use them properly in multi-threaded environment. After studying the HAL library, it became apparent that the HAL drivers for crypto are not thread safe. There is a define in HAL driver lib ''USE_RTOS'' or something along those lines, which is currently defined as 0 with the comment that in the future it will be available. Any plans on making the HAL thread-safe? Please let us know since its a shame not to use the hw crypto when its available to speed up tsl etc.

[Tesla DeLorean]

Posted on January 24, 2016 at 02:12

I don't think the hardware allows for a context change, you're going to have manage/serialize access to the resource.

[mark239955_stm1]

Posted on January 28, 2016 at 01:56

There's some discussion in the STM32F41x/43x reference manual in the CRYP peripheral documentation, under ''Context Switching'', that might be of use.  Page 736 of revision 11.

[cipher]

Posted on February 06, 2016 at 05:27

you are totally right! i missed it in the manual

Thanks for pointing it out. Now question to ST: any chance of supporting the context save/restore of CRYPT/HASH peripherals in HAL or crypto lib in the near future?