Compilation error when defining OPENSSL_ALL or OPENSSL_EXTRA on ESP-IDFv5 : ssl.c:18011:22: error: size of array 'sha_test' is negative

[llange]

Version

tag v5.5.4-stable or master

Description

Compiling OVMSv3 for ESP-IDF version 5+ (NOT using the component integration (https://github.com/espressif/esp-wolfssl/)) - like in #6024 , #6026

Also I'm targeting the ESP32 target (not ESP32-S3 etc...)

When enabling either OPENSSL_ALL or OPENSSL_EXTRA (or both) in user_settings.h, the compilation fails with:

[103/255] Building C object esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/src/ssl.c.objFAILED: esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/src/ssl.c.obj 
SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -DWOLFSSL_USER_SETTINGS -ISRCS/OVMS-wt2/vehicle/OVMS.V3/build/config -ISRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/port -ISRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl -ISRCS/ESP-IDF/5.0/components/newlib/platform_include -ISRCS/ESP-IDF/5.0/components/freertos/FreeRTOS-Kernel/include -ISRCS/ESP-IDF/5.0/components/freertos/esp_additions/include/freertos -ISRCS/ESP-IDF/5.0/components/freertos/FreeRTOS-Kernel/portable/xtensa/include -ISRCS/ESP-IDF/5.0/components/freertos/esp_additions/include -ISRCS/ESP-IDF/5.0/components/esp_hw_support/include -ISRCS/ESP-IDF/5.0/components/esp_hw_support/include/soc -ISRCS/ESP-IDF/5.0/components/esp_hw_support/include/soc/esp32 -ISRCS/ESP-IDF/5.0/components/esp_hw_support/port/esp32/. -ISRCS/ESP-IDF/5.0/components/esp_hw_support/port/esp32/private_include -ISRCS/ESP-IDF/5.0/components/heap/include -ISRCS/ESP-IDF/5.0/components/log/include -ISRCS/ESP-IDF/5.0/components/soc/include -ISRCS/ESP-IDF/5.0/components/soc/esp32/. -ISRCS/ESP-IDF/5.0/components/soc/esp32/include -ISRCS/ESP-IDF/5.0/components/hal/esp32/include -ISRCS/ESP-IDF/5.0/components/hal/include -ISRCS/ESP-IDF/5.0/components/hal/platform_port/include -ISRCS/ESP-IDF/5.0/components/esp_rom/include -ISRCS/ESP-IDF/5.0/components/esp_rom/include/esp32 -ISRCS/ESP-IDF/5.0/components/esp_rom/esp32 -ISRCS/ESP-IDF/5.0/components/esp_common/include -ISRCS/ESP-IDF/5.0/components/esp_system/include -ISRCS/ESP-IDF/5.0/components/esp_system/port/soc -ISRCS/ESP-IDF/5.0/components/esp_system/port/include/private -ISRCS/ESP-IDF/5.0/components/xtensa/include -ISRCS/ESP-IDF/5.0/components/xtensa/esp32/include -ISRCS/ESP-IDF/5.0/components/esp_timer/include -ISRCS/ESP-IDF/5.0/components/lwip/include -ISRCS/ESP-IDF/5.0/components/lwip/include/apps -ISRCS/ESP-IDF/5.0/components/lwip/include/apps/sntp -ISRCS/ESP-IDF/5.0/components/lwip/lwip/src/include -ISRCS/ESP-IDF/5.0/components/lwip/port/esp32/include -ISRCS/ESP-IDF/5.0/components/lwip/port/esp32/include/arch -mlongcalls -Wno-frame-address  -fdiagnostics-color=always -ffunction-sections -fdata-sections -Wall -Werror=all -Wno-error=unused-function -Wno-error=unused-variable -Wno-error=deprecated-declarations -Wextra -Wno-unused-parameter -Wno-sign-compare -Wno-enum-conversion -gdwarf-4 -ggdb -Os -freorder-blocks -fmacro-prefix-map=SRCS/OVMS-wt2/vehicle/OVMS.V3=. -fmacro-prefix-map=SRCS/ESP-IDF/5.0=/IDF -fstrict-volatile-bitfields -Wno-error=unused-but-set-variable -fno-jump-tables -fno-tree-switch-conversion -DconfigENABLE_FREERTOS_DEBUG_OCDAWARE=1 -std=gnu17 -Wno-old-style-declaration -D_GNU_SOURCE -DIDF_VER=\"v5.0\" -DESP_PLATFORM -D_POSIX_READER_WRITER_LOCKS -Wno-cpp -Wno-char-subscripts -Wno-format-truncation -Wno-char-subscripts -MD -MT esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/src/ssl.c.obj -MF esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/src/ssl.c.obj.d -o esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/src/ssl.c.obj -c SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/src/ssl.c
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/src/ssl.c: In function 'wolfSSL_SHA_Init':
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/src/ssl.c:18011:22: error: size of array 'sha_test' is negative
18011 |         typedef char sha_test[sizeof(SHA_CTX) >= sizeof(wc_Sha) ? 1 : -1];
      |                      ^~~~~~~~

Otherwise it does compile perfectly if I don't enable these 2 defines.

Here is user_settings.h (the defines are commented out on lines 40 and 41):
user_settings.h.txt

I understood that ESP-IDF defines also this typedef (SHA_CTX), and that a specific workaround was necessary in

wolfssl/wolfssl/wolfcrypt/port/Espressif/esp32-crypt.h

Lines 104 to 112 in bdcf692

	#define SHA_CTX ETS_SHAContext
	#if ESP_IDF_VERSION_MAJOR >= 4
	#include "esp32/rom/sha.h"
	#else
	#include "rom/sha.h"
	#endif
	#undef SHA_CTX

It may be related, or something completely different, but I lack experience with the codebase to understand exactly why this "assertion" fails.

[llange]

+@gojimmypi FYI

[gojimmypi]

Hi @llange - does your project need the OpenSSL compatibility layer? Given that your project compiles without that enabled, I suspect not. I'm interested in why you might have wanted to turn on that feature? I think it is only meant for users with a large codebase that previously used OpenSSL and then later upgraded to wolfSSL.

In any case, that's an interesting problem. Even if you don't need the OpenSSL compatibility layer in your project, we should not see that error when turning on that feature.

Thanks again for your time to report these issues. Feel free to report any other concerns or observations.

[llange]

Hi @gojimmypi, thanks for the comment.
The component that may use it is disabled at the moment, and still I'm not 100% sure that it's even used. (It's a matter of multiple conditional defines).
But as it was defined in the codebase I'm pretty sure it was compiling fine with previous version of wolfssl (4.7.1r)

[gojimmypi]

Hi @llange - thanks for the update. Even if not used in your project, I'd like to get this fixed up.

It appears the OpenSSL errors are related to HW hash acceleration.

To turn off that feature, disable with NO_WOLFSSL_ESP32WROOM32_CRYPT_HASH in user_settings.h:

/* when you want not to use HW acceleration */
/* #define NO_ESP32WROOM32_CRYPT */
#define NO_WOLFSSL_ESP32WROOM32_CRYPT_HASH
/*  #define NO_WOLFSSL_ESP32WROOM32_CRYPT_AES */
/*  #define NO_WOLFSSL_ESP32WROOM32_CRYPT_RSA_PRI */

We should see this new output in the wolfssl_test with the hash accleration turned off:

...
PWDBASED test passed!
OPENSSL  test passed!
OPENSSL (EVP MD) passed!
OPENSSL (PKEY0) passed!
OPENSSL (PKEY1) passed!
OPENSSL (EVP Sign/Verify) passed!
ECC      test passed!
...

To fix the size error noted above with acceleration turned on, the initialization noted in #6035 is needed as well as this line added in sha.h:

#elif defined(WOLFSSL_ESPWROOM32) && !defined(NO_WOLFSSL_ESP32WROOM32_CRYPT_HASH)
    void* holder[(112 + WC_ASYNC_DEV_SIZE + sizeof(WC_ESP32SHA)) / sizeof(void*)];

That's not the final solution, so no PR yet as the OpenSSL tests are failing for me with acceleration turned on:

RSA      test passed!
PWDBASED test passed!
OPENSSL  test failed!
 error = -8722
I (11882) wolfcrypt_test: Exiting main with return code: -1

E (11882) wolfssl_test: wolf_test_task FAIL result code = -1

See my Espressif_OpenSSL_interim branch for WIP.

[llange]

Hi @gojimmypi , just a quick thank you for your time and work and these ESP-related issues. Very appreciated !
As I'm progressing in the compilation of the OVMS codebase I also would like to share that indeed, this OPENSSL mode is used by the project, when selecting some default options (it's just that I had those options disabled when doing my porting, for limiting the perimeter).
So this is all the more important :-) and I'll try to see how I can help.

[gojimmypi]

Hi @llange glad to help. I think the current problem with OpenSSL may in fact be related to #5948 - I have not yet updated that issue, but I currently believe the root cause is more related to proper initialization of a new SHA hash ctx object and not the alignment issue (despite compelling evidence to the contrary) - in particular initialization of the hardware state struct probably needs attention. I need to spend more time with that.

Perhaps in the meantime during your development you could just turn that feature off with NO_WOLFSSL_ESP32WROOM32_CRYPT_HASH until this gets fixed.

[PaulMartinsen]

I found this after hitting the same error when enabling OPENSSL_EXTRA. I'm not using the OpenSSL compatibility layer, as I understand it. But I wanted to check certificates for expiry and authenticate based on the presence of policy information. For that I needed:

• wolfSSL_X509_load_certificate_file
• wolfSSL_X509_get_notAfter
• wolfSSL_X509_free
• wolfSSL_X509_get_ext_d2i
• CERT_POLICY_OID

I noticed that defining KEEP_PEER_CERT, SESSION_CERTS, or OPENSSL_EXTRA_X509_SMALL could have made some of these available, but most aren't documented, I was worried about side effects and I hit various compile time errors.

I got enough functionality to read a certificate expiry date by adding my own config option. But trying to enable wolfSSL_X509_get_ext_d2i quickly ballooned into repercussions I wasn't prepared for.

Anyway, I'm not sure why any of the above would be limited to OpenSSL compatibility. Am I using the wrong functions? My hope, @llange, is if we can identify the specific functionality we need from "OPENSSL_EXTRA" it may be easier to enable than addressing all of OPENSSL_EXTRA.

[gojimmypi]

I found that the SHA-512/224 fails on the Espressif ESP32. See my new tests in #6097

When turning on OPENSSL_EXTRA the wolfSSL_SHA512_224_Final() fails in evp.c when hardware acceleration is on, otherwise works when in software mode.

I expect to complete a fix in the near future.

[gojimmypi]

Hi @llange and @PaulMartinsen - I believe this issue was fixed with #6287

There's still a minor problem with ESP32-S3 AES-192 HW acceleration as noted in #6375

Could you please take it for a test drive and confirm the OpenSSL settings no longer cause a problem?

See #6234 for Espressif Roadmap and related updates.

Thank you.

[PaulMartinsen]

Hi @gojimmypi , I merged in the WolfSSL/master branch and can confirm there's no longer a problem with #define OPENSSL_EXTRA in my user_settings.h.

During testing I was getting Unknown pilot attribute type errors when loading a certificate on the ESP32s3 that I'd created with an earlier version of the library (your ED25519_SHA2_fix from 17 March). I didn't see the same error running on Windows. After creating a new 1024-bit private key on the ESP32s3 and signing it with OpenSSL, this problem went away. I ran out of time to explore further but I thought I'd mention it in light of #6205. Not sure if that's just a coincidence or a secondary thing.