[Bug]: esp32_sha.c:511:26: error: lvalue required as left operand of assignment

[llange]

Contact Details

No response

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

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

So I understood that the default configuration does not enable SHA384, which may be the reason I seem to be struggling with some compile-time issues :-)

So it seems that 8bb6ff8 also introduced the following construct :

...
        case SHA1:
            DPORT_REG_WRITE(SHA_1_LOAD_REG, 1);
            break;

        case SHA2_256:
            DPORT_REG_WRITE(SHA_256_LOAD_REG, 1);
            break;

    #if defined(WOLFSSL_SHA384)
        case SHA2_384:
            SHA_LOAD_REG = SHA_384_LOAD_REG;
            SHA_BUSY_REG = SHA_384_BUSY_REG;
            break;
    #endif

    #if defined(WOLFSSL_SHA512)
        case SHA2_512:
            DPORT_REG_WRITE(SHA_512_LOAD_REG, 1);
            break;
    #endif
... 

As you can see, in the case of SHA2_384 the behaviour (assignment) is not the same as for the 3 other cases (register write).

Those 2 (variables ? constants ?) SHA_LOAD_REG and SHA_BUSY_REG are not defined (nor used) in wolfssl but there are indeed 2 functions in ESP-IDF with the same name.

However it fails to compile for sure - may be it depends on the ESP-IDF version (I'm using 5.0), or on the target ?

This is not a field I'm experimented with, but after reading the ESP32 Technical Reference Manual (chapter 23.3.3, top of page 579) my suggestion would be:

@ wolfcrypt/src/port/Espressif/esp32_sha.c:510 @ int wc_esp_digest_state(WC_ESP32SHA* ctx, byte* hash)
 
     #if defined(WOLFSSL_SHA384)
         case SHA2_384:
-            SHA_LOAD_REG = SHA_384_LOAD_REG;
-            SHA_BUSY_REG = SHA_384_BUSY_REG;
+            DPORT_REG_WRITE(SHA_384_LOAD_REG, 1);
             break;
     #endif
 

which does compile for ESP32, and looks consistent with the other use of registers for SHA_384 in the same file:

• SHA_384_START_REG
• SHA_384_CONTINUE_REG

+@gojimmypi FYI (Sorry to annoy you with this 7 months old patch of yours...)

Reproduction steps

No response

Relevant log output

[2/173] Building C object esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c.objFAILED: esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.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 -MD -MT esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c.obj -MF esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c.obj.d -o esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c.obj -c SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c: In function 'wc_esp_digest_state':
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c:511:26: error: lvalue required as left operand of assignment
  511 |             SHA_LOAD_REG = SHA_384_LOAD_REG;
      |                          ^
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c:512:26: error: lvalue required as left operand of assignment
  512 |             SHA_BUSY_REG = SHA_384_BUSY_REG;
      |                          ^

[gojimmypi]

@llange thanks for finding this. Yes, there's definitely a problem with HW acceleration under some circumstances as recently detected by the ED25519 test failure noted in #5948. I'm actively working on this in my ED25519_SHA2_fix branch.

Although full support for the ESP-IDF version 5 is well underway, I have left open #5909 and #5319 until all wolfSSL Espressif projects have been confirmed to be working with v5.

You may be interested in my "no install" wolfSSL in #6018

btw - Thanks again for taking a look. What's your use case for wolfSSL? I'm always interested in learning what new ESP32 projects are using wolfSSL.

[llange]

The project is OVMSv3 - basically, the firmware for an open-source vehicle telemetry unit - electric vehicle remote monitoring, diagnosis and control - (but in fact much more than that) : you buy/build the HW, plug it in a car, and from your Lab/Home/Server you can gather data, send commands, track it, etc...
You can have a look at https://www.openvehicles.com/ and/or https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/tree/master/vehicle/OVMS.V3

To the best of my knowledge (I'm a recent contributor and don't know the whole story), this firmware is using wolfSSL (and wolfSSH) since 2017 it seems ; for both an SSH server (console_ssh) and a Web Server based on mongoose for which it is an optional TLS provider (alongside mbedTLS).

The FW is based on "non-current" versions of ESP-IDF (a custom fork of 3.3.6), wolfSSL (4.7.0) and woldSSH (1.4.6), and so I foolishly decided to help porting it to more recent versions.
ESP-IDF upgrade to v5 being successfully done ; wolfSSL, with mongoose, are the last pieces that I need to update before I can start collecting the pieces to make a PR (for OVMSv3).

I'll certainly have a look at your "no install" examples, although my cmake knowledge is too minimal for understanding all the beauty of the implementation, but I can certainly get inspired by them.

[llange]

Thank you @gojimmypi for the merged PR.