This issue is not serious and more a potential for HW acceleration performance improvements.
While working on https://github.com/wolfSSL/wolfMQTT/issues/352 I noticed a curious situation in the SHA hardware accelerator where the hardware lock is not able to be obtained. The code otherwise does not know the HW is busy and should have already been in SW fallback mode. This is observed in my upcoming Espressif AWS_IoT_MQTT Example.
This undesired situation is captured and handled properly in esp_sha_try_hw_lock() - but the unexpected condition triggers many verbose messages when not debugging.
I have https://github.com/wolfSSL/wolfssl/pull/6811 to wrap that line in debugger gate macro, but this issue is for investigation as to how and why the hardware lock is not able to be maintained in wolfMQTT.
In wolfSSL, I've seen similar problems where a copy of a ctx object was used. I believe I've handled that in the merge of https://github.com/wolfSSL/wolfssl/pull/6624 by keeping track of the address of the object that initialized the respective object: when the initialize is not equal to the address of the current object, it must be a copy.
The other place to look is the TLS session that may start multiple, concurrent hashes and never actually finish. Still, the code should have anticipated this. It may be that the code handling the TLS connection and the code for wolfMQTT that may want to perform a HW hash, when running independently, may simply not know about each other having a HW lock or not.
This issue is not serious and more a potential for HW acceleration performance improvements.
While working on https://github.com/wolfSSL/wolfMQTT/issues/352 I noticed a curious situation in the SHA hardware accelerator where the hardware lock is not able to be obtained. The code otherwise does not know the HW is busy and should have already been in SW fallback mode. This is observed in my upcoming Espressif AWS_IoT_MQTT Example.
This undesired situation is captured and handled properly in
esp_sha_try_hw_lock()- but the unexpected condition triggers many verbose messages when not debugging.I have https://github.com/wolfSSL/wolfssl/pull/6811 to wrap that line in debugger gate macro, but this issue is for investigation as to how and why the hardware lock is not able to be maintained in wolfMQTT.
In wolfSSL, I've seen similar problems where a copy of a
ctxobject was used. I believe I've handled that in the merge of https://github.com/wolfSSL/wolfssl/pull/6624 by keeping track of the address of the object that initialized the respective object: when theinitializeis not equal to the address of the current object, it must be a copy.The other place to look is the TLS session that may start multiple, concurrent hashes and never actually finish. Still, the code should have anticipated this. It may be that the code handling the TLS connection and the code for wolfMQTT that may want to perform a HW hash, when running independently, may simply not know about each other having a HW lock or not.
The proper solution is to implement HW interleave mentioned in https://github.com/wolfSSL/wolfssl/issues/6637.
See https://github.com/wolfSSL/wolfssl/issues/6234 for a roadmap of all Espressif improvements currently in progress.