esp-idf: System crashes when connecting to TLS-enabled httpd right after successful (universal) provisioning (IDFGH-4662)

Environment

  • Development Kit: none
  • Module or chip used: ESP32-WROOM-32D
  • IDF version: v4.2-238-g8cd16b60f
  • Build System: idf.py
  • Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2020r3) 8.4.0
  • Operating System: Arch Linux
  • Using an IDE?: No
  • Power Supply: USB

Problem Description

Using the httpd-component with WolfSSL results in a crash if one connects to the server after a successful provisioning of the device. After a reboot initiated by an external reset one can contact the https-server without crashing the system. I have also tested upstream WolfSSL (with modifications to use it with esp-tls) to debug this. I tried versions 4.{3,4,5,6} and all exhibit the same problem. The crash does not happen if I build WolfSSL with NO_WOLFSSL_ESP32WROOM32_CRYPT_RSA_PRI.

Expected Behavior

System should not crash.

Actual Behavior

System crashes.

Steps to reproduce

You need an ESP32-WROOM-32D potentially with a MFI-Chip. Use WolfSSL as TLS-Library, provision the device with universal provisioning, start a https-server after a successful provisioning and connect to it using curl/openssl.

Code to reproduce this issue

See https://github.com/dbahrdt/esp-wolfssl-provisioning-crash. Simply edit tools/debuggin/cfg to your needs and rename it to .cfg. The script energize will:

  1. Create temporary factory_nvs data
  2. Temporary CA+server-certificate+sign it
  3. Build the project
  4. Flash the project and the factory_nvs data
  5. Start the app using idf.py monitor
  6. Provision the device using universal provisioning (connection to the wifi network “mwe-wolfssl-crash” is not done automatically)

After a successful provisioning you may use curl to connect to the device:

curl --cacert components/web/certs/ca.pem https://mwe.lan:4443/test

Debug Logs

Crash log: https://gist.github.com/dbahrdt/706a8e6fff4118e6b728f28001979a9f

I (80587) esp_https_server: performing session handshake
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x401aafcf  PS      : 0x00060c30  A0      : 0x80178726  A1      : 0x3ffd57c0  
0x401aafcf: fp_lshd at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:3214 (discriminator 2)

A2      : 0x3ffdbdd8  A3      : 0xffffffbf  A4      : 0x3ffdbdd8  A5      : 0x00000040  
A6      : 0x00000001  A7      : 0x00000022  A8      : 0x9cb0cdd0  A9      : 0x172cc3ff  
A10     : 0x172cc3fe  A11     : 0x00000087  A12     : 0x58326e78  A13     : 0x00000001  
A14     : 0x3ffdb6d4  A15     : 0x00000022  SAR     : 0x00000001  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x9cb0cdd8  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

Backtrace:0x401aafcc:0x3ffd57c0 0x40178723:0x3ffd57e0 0x4017898a:0x3ffd5830 0x40178c63:0x3ffd5850 0x40178eda:0x3ffd5870 0x40179349:0x3ffd58c0 0x4017936a:0x3ffd58e0 0x4016bf9e:0x3ffd5900 0x4016c2ad:0x3ffd5940 0x4016c6de:0x3ffd5980 0x4016c7d5:0x3ffd59d0 0x4016c7fa:0x3ffd5a10 0x4017b7ed:0x3ffd5a40 0x40182567:0x3ffd5a80 0x4015906c:0x3ffd5b00 0x4011fe3d:0x3ffd5b20 0x4011f6f9:0x3ffd5b40 0x400dea04:0x3ffd5b60 0x401213a6:0x3ffd5b80 0x4011ffaa:0x3ffd5bb0 0x4012014b:0x3ffd5c00 0x40120187:0x3ffd5c40 0x40088c15:0x3ffd5c60
0x401aafcc: fp_lshd at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:3214 (discriminator 2)

0x40178723: fp_div at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:642

0x4017898a: fp_mod at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:834

0x40178c63: fp_mulmod at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:1173

0x40178eda: _fp_exptmod at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:1526

0x40179349: fp_exptmod at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:2267

0x4017936a: mp_exptmod at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/tfm.c:3531

0x4016bf9e: wc_RsaFunctionSync at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/rsa.c:2148 (discriminator 1)

0x4016c2ad: wc_RsaFunction at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/rsa.c:2656

0x4016c6de: RsaPublicEncryptEx at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/rsa.c:2776

0x4016c7d5: wc_RsaPSS_Sign_ex at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/rsa.c:3501

0x4016c7fa: wc_RsaPSS_Sign at /builds/esp-components/esp-wolfssl/wolfssl/wolfcrypt/src/rsa.c:3477

0x4017b7ed: RsaSign at /builds/esp-components/esp-wolfssl/wolfssl/src/internal.c:3640

0x40182567: SendServerKeyExchange at /builds/esp-components/esp-wolfssl/wolfssl/src/internal.c:24196

0x4015906c: wolfSSL_accept at /builds/esp-components/esp-wolfssl/wolfssl/src/ssl.c:11975

0x4011fe3d: esp_wolfssl_server_session_create at ${IDF_PATH}/components/esp-tls/esp_tls_wolfssl.c:444

0x4011f6f9: esp_tls_server_session_create at ${IDF_PATH}/components/esp-tls/esp_tls.c:451

0x400dea04: httpd_ssl_open at ${IDF_PATH}/components/esp_https_server/src/https_server.c:104 (discriminator 13)

0x401213a6: httpd_sess_new at ${IDF_PATH}/components/esp_http_server/src/httpd_sess.c:79

0x4011ffaa: httpd_accept_conn at ${IDF_PATH}/components/esp_http_server/src/httpd_main.c:65 (discriminator 15)

0x4012014b: httpd_server at ${IDF_PATH}/components/esp_http_server/src/httpd_main.c:213 (discriminator 15)

0x40120187: httpd_thread at ${IDF_PATH}/components/esp_http_server/src/httpd_main.c:229 (discriminator 15)

0x40088c15: vPortTaskWrapper at ${IDF_PATH}/components/freertos/xtensa/port.c:143

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 22 (11 by maintainers)

Most upvoted comments

Hi @AdityaHPatwardhan,

thanks for the info. I’ve tested your suggestions and results are looking good. I have also implemented support for rfc 5077 session tickets for which I’ll open a PR next week.

Regarding the bug, are you going to report this at WolfSSL? Since this is entirely in upstreams code they should be the one to fix it.