[TW#13567] mbedtls sample fails when allocating mbedts_ssl_context on heap #711
Comments
|
You're certainly checking the return value of And since you didn't indicate that it ever worked with your config and without your modification on the ESP32, we cannot be sure that you're not simply facing a stack overflow, either. (Even if it works without your modification, a potential stack overflow can go unnoticed in one case and mess up everything in the other.) |
|
Yep, definitely getting a valid pointer back. And it does work if I put the mbedtls_ssl_context struct on the stack. Here's a gist: https://gist.github.com/SteveOfTheStow/d8109991384f032edcb2de406a78e7a4 |
|
Again, the stack could be corrupted, and it could have a different effect in both cases due to the different stack layout, so is your build configured for stack overflow, or not? |
|
I've got "Check by stack pointer value". Note that the same occurs if I turn off Checking. |
|
Did you include the .pem file? |
|
I was using the built-in mbedtls test cert, but I've just tried a separate pem using COMPONENT_EMBED_FILES and it's the same backtrace. Here's the output of IDF Monitor: Guru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. A2 : 0x3ffc868c A3 : 0x00000000 A4 : 0xff000000 A5 : 0x80ffffff Backtrace: 0x4008327b:0x3ffd68b0 0x400833d8:0x3ffd68d0 0x4008624b:0x3ffd68f0 0x4008628c:0x3ffd6910 0x40081a94:0x3ffd6930 0x4000bef8:0x3ffd6950 0x401234ec:0x3ffd6970 0x40115c6a:0x3ffd69c0 0x400def86:0x3ffd6a10 0x400833d8: pvPortMallocTagged at ~/bin/espressif/esp32/esp-idf/components/freertos/./heap_regions.c:410 0x4008624b: pvPortMallocCaps at~/bin/espressif/esp32/esp-idf/components/esp32/./heap_alloc_caps.c:414 0x4008628c: pvPortMalloc at ~/bin/espressif/esp32/esp-idf/components/esp32/./heap_alloc_caps.c:414 0x40081a94: _calloc_r at ~/bin/espressif/esp32/esp-idf/components/newlib/./syscalls.c:56 0x401234ec: mbedtls_pem_read_buffer at ~/bin/espressif/esp32/esp-idf/components/mbedtls/library/pem.c:332 (discriminator 1) 0x40115c6a: mbedtls_x509_crt_parse at ~/bin/espressif/esp32/esp-idf/components/mbedtls/library/x509_crt.c:1253 0x400def86: ssl_task at ~/Dev/src/Practice/Platform_Specific/ESP32/mbedtls_test/main/./main.c:112 I'm sure there's some way to get this to work using mbedtls_ssl_context as a pointer. It does work before I made ssl a pointer, yep. |
|
Searching for prvInsertBlockIntoFreeList, I found this, which provides a good theory about what the malloc might be up to, though I don't understand the 'why' or how to work around it yet. |
|
@SteveOfTheStow again, Before you made ssl a pointer, the program worked? As that post you reference suggests, it might be a heap corruption issue. You should check the rest of your code for malloc'ed structs you manipulate that might go out of bounds. |
|
Yes, it works before I made ssl a pointer. |
|
I compared the sdkconfig for both the referenced mbedtls client sample in ESP-IDF and, and the project I created using mbedtls's own c file sample. I don't know why this is. Unfortunately the program I'm writing that uses mbedtls still suffers from the issue of failing on parsing certs, as described above (a couple of lines of backtrace are copied below) after these modifications are made. 0x401234ec: mbedtls_pem_read_buffer at ~/bin/espressif/esp32/esp-idf/components/mbedtls/library/pem.c:332 (discriminator 1) 0x40115c6a: mbedtls_x509_crt_parse at ~/bin/espressif/esp32/esp-idf/components/mbedtls/library/x509_crt.c:1253 |
|
Could you share the source code? Ill try to reproduce. |
|
99% of the code is just using ESP-IDF right now so I'd just need to change a bunch of entity names and I could probably share it sometime this week. |
|
I'm still on the memory corruption track. When exactly does your sever start as compared to WiFi? I'm not using any malloc()ed stuff in my own code so I that could be a reason why I do not encounter any runtime problems except the failing connect. Actually, since all my memory gets allocated before WiFi starts, there's no chance for the WiFi lib to access any memory which was freed and now belongs to me (rather, it will mess up its own former memory, which I never used). In your case, depending on the startup sequence, it's possible that the root cause is actually WiFi going wild, accessing memory via a pointer to formerly own memory which is now yours. If you allocate that memory before everything else and pass it to your server's |
FayeY
changed the title
|
Here's a sample version of the app I'm building: https://github.com/SteveOfTheStow/esp_mbedtls_test
|
|
@HubbyGitter Thanks for the tip. Not sure I could allocate everything before starting WiFi, especially bits that depend on it. |
|
@SteveOfTheStow To clarify, my suggestion was meant for helping to find the root cause, not as a solution for a working system. |
|
Fair. Was actually fine to swap around starting the SSL/UART connectivity and the WiFI, and it still broke in the same place alas. |
|
To work around this bug, remove the call to Why is this a bug? IDF ships its own mbedTLS config header, The size of various mbedTLS structures depends on the config items enabled. This manifests as a crash due to heap corruption. The same memory corruption still happens when mbedtls_ssl_context is allocated on the stack, it just happens to not corrupt any stack memory in a way that causes a crash. I'm going to leave this Issue open for now because we should either remove the default config header, or provide a way to detect if it's accidentally included directly into a source file. PS While looking for this I noticed another memory corruption bug here: |
|
Fix for the underlying issue is coming (including "mbedtls/config.h" directly will include the correct configuration.) |
|
Many thanks! |
…" directly in program Previously this resulted in a config mismatch between default config and esp_config.h Closes espressif/esp-idf#711
(Also posted on esp32.com but not approved yet so cross-posted here)
I'm trying to use mbedtls in the ESP-IDF and have grabbed the mbedtls server sample program from here. It largely maps fine into an ESP32 model. The one major change I tried to do was to allocate mbedtls_ssl_context on the heap (I need this to use mbedtls in a larger program I'm building), and this seems to blow up the program when it tries to parse certs.
I've tried this change on the sample and run on macOS; works fine.
Change:
mbedtls_ssl_context ssl;becomes
mbedtls_ssl_context *ssl = malloc(sizeof(mbedtls_ssl_context));(and all the uses of &ssl become ssl)
Logs from ESP32:
The call that causes things to go bang is:
ret = mbedtls_x509_crt_parse( &srvcert, (const unsigned char *) cacert_pem_start, cacert_pem_bytes );which doesn't even use the allocated struct.
After a stop in x509_crt.c: 1015, we get to:
then:
and further into the system.
The text was updated successfully, but these errors were encountered: