-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MD5, SHA1 and SHA256 hardware acceleration not working for STM32F439xI #5079
Comments
STM32F439xI-family MD5, SHA1 and SHA256 hardware acceleration occasionally produces incorrect output (ARMmbed#5079). Don't enable MD5, SHA1 and SHA256 HW acceleration on STM32F439xI-family targets by default until issue ARMmbed#5079 is fixed.
I have created PR #5080 that disables HW acceleration for the relevant primitives. This is only a workaround though. |
@adustm: My understanding is that the following targets all share the same hardware acceleration code:
Do you think they all have similar issues? Unfortunately I do not have the hardware to test them all and report my findings... |
Hello @andresag01 I filnalize the AES then I come back on this one. I'll check at the same time the behavior of other families. kind regards |
By the way, Mihail has all the platforms you are missing :) |
Many thanks for taking a look. Please let me know if there is anything else I can do to help.
Thats a very good point, I had not considered that... My guess is that the test I am currently using is slightly more stressful and uses at least double the amount of contexts. Also, there is a lot of interleaving. Of course, there is also a chance that I made a mistake in the test, but I havent found any indication of this yet.
Thanks for letting me know! I will speak with Mihail's team and see what I can get
Thanks for checking this. I think that would be ideal given that the code is mostly shared between all the devices. I will also try to get a hold of the boards and run a couple of quick tests myself. |
In case it's useful, I've was seeing failures of DTLS/UDP handshakes against mbed Cloud server on the Ublox Odin W2. On 5.6.0, with the crypto acceleration enabled, it fails, but on 5.6.1 with it disabled it works. But what's odd, and that I can't explain is that TLS/TCP handshakes did actually work on the same system in 5.6.0 with the hardware crypto enabled. I can't see any difference in what mbed TLS is doing between DTLS and TLS with regards to the calls to crypto. My current best guess is an alignment difference, but I'm far from certain of that. So when you have a fix for the interleaving, I'd be interested in checking it on that DTLS case - I am wondering if the failure cause is something other than interleaving that you've yet to discover. My second concern is that looking at #5018, I see protection against interleaved crypto operations on a single thread, but I'm not seeing any multithreading protection - doesn't it need a mutex to prevent a second thread touching the hardware between your "restore context" and the actual operation? You should have a test case that does kind of the same thing as above, but with AES_CTX_COUNT threads. |
@kjbracey-arm: Thanks for your input. Please note that I have created #5036 to add more stress tests like the one you are suggesting. |
Hello @andresag01 The internal state machine of ST HAL code assumes that you've been through it even for an empty buffer. I can easily fix that, in case any user wants to optimize its application and avoid calling _update in case of empty buffer. My PR is ready, but I am not able to test MD5. It does not link.
I've added the test at the root of mbed-os and typed I get the following link error
How to enable MBEDTLS_MD5_C ? Kind regards |
@adustm can you try un-commenting line https://github.com/ARMmbed/mbed-os/blob/master/features/mbedtls/inc/mbedtls/config.h#L2046 |
Hi @adustm, my apologies for the delay in my reply. I am not sure if putting the application inside the mbed-os directory works. My understanding is that this directory should only contain the library code and tests, but the stress test that I wrote is written as if it was a user application. To test this, I normally just replace the code in the main.cpp of one of the applications at mbed-os-example-tls and then use it as normal. To illustrate this, I have done the setup for you in here in my fork which is ready to deploy your mbed-os fork and test the change with the normal After trying that I also found that the linking problem persists and tracked it down to a misplaced include in the file md5_alt.h. The following change fixes the problem as
I hope this helps, and once more, apologies for the delay to reply. Let me know if there are any further questions, but please note that I am currently not directly involved in the development of hardware acceleration APIs so it might take me a little time to reply. |
Thanks @andresag01 . Moving |
…if mbedtls_xxx_udate was not called since mbedtls_xxx_start
Fix #5079. Support of call to mbedtls_x_finish without calling mbedtls_x_update
…tls_xxx_udate was not called since mbedtls_xxx_start
Description
This problem seems to be closely related to #4928, which is a failure in AES hardware acceleration for STM32F439xI family of targets only. The cause of the failures seems to be that the hardware acceleration code for these targets cannot correctly handle interleaved operation of multiple mbedtls contexts for the SHA1, MD5 and SHA256 crypto primitives. I have written the following test that exercises the problem:
Bug
Target
STM32F439xI family of devices with hardware acceleration enabled
Toolchain:
GCC_ARM
mbed-os sha:
5e437fe
Expected behavior
The test should succeed.
Actual behavior
The tests for MD5, SHA1 and SHA256 fail
Steps to reproduce
Compile and run the test above in a STM32F439xI device, e.g. UBLOX_EVK_ODIN_W2. The failures will be printed in the serial terminal.
The text was updated successfully, but these errors were encountered: