Just finishing off this thread:
The issue appeared due to an invalid pointer access else where in the application that coincided with the mbedtls_ssl_set_bio function.
Working on resolution now.
Thanks for all the help, pointers & hints from the list!
On 2021-06-08 2:27 p.m., Ron Eggler via mbed-tls wrote:
Yes, there's some kind of "memory magic" going on here:
The task got terminated due to "Load from invalid memory"
and I see:
|Instruction at 0x6310604d is trying to load data at 0x4, which is an invalid memory area. You are probably dereferencing a NULL pointer.|
|and i got some trace back addresses that point to:|
mbedtls_aes_crypt_ecb
mbedtls_ctr_drbg_random_with_add
mbedtls_ssl_handshake_step
mbedtls_ssl_handshake
||
On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote:
Hi Ron,
This behavior can't be explained by the library code and the code you posted alone. There has to be something wrong elsewhere.
Check that you aren't exceeding a limitation such as the stack size or the size of executable and data sections. If it can be an issue on your platform, check that load addresses are correct and sections don't overlap. Make sure there's no overlap with any device memory mapping either.
Make sure that the whole binary is compiled with consistent settings. The layout of mbedtls_ssl_context can be influenced by the Mbed TLS configuration, so make sure that there's a single copy of mbedtls/config.h and both Mbed TLS itself and your application were built against that copy. The layout of mbedtls_ssl_context can also be influenced by compiler settings on some platforms (e.g. structure packing options), so make sure those are consistent across your build.
That's all I can think of for now. It may help to add a lot of printf debugging with %p on various addresses, and compare these addresses with what you know about memory mappings on that platform. Good luck!