ESP32 Stack canary watchpoint triggered. Miért?

Címkék
ESP32 Stack canary watchpoint triggered. Miért?
2021-04-27T09:47:37+02:00
2021-04-28T20:12:51+02:00
2022-08-12T02:20:30+02:00
Arpsoft
Sziasztok!

Van egy fura problémám. Van egy program, ami a Boneh-Franklin titkosítással tud titkosítani és visszafejteni egy szöveget. Ez remekül működik PC-n, de valamiért ESP32-n folyamatos újraindulást okoz a következő hibaüzenettel:

setup2 setup2.2 setup2.3 setup2.4 kkkk encrypt Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception) Debug exception reason: Stack canary watchpoint triggered (loopTask) Core 1 register dump: PC : 0x400f1d62 PS : 0x00060936 A0 : 0x800d6930 A1 : 0x3ffafec0 A2 : 0x3ffb0050 A3 : 0x3ffaff60 A4 : 0x3ffaffb0 A5 : 0x00000000 A6 : 0x00000000 A7 : 0x00000006 A8 : 0x00000010 A9 : 0x00000014 A10 : 0x138c0b15 A11 : 0x3ffb0060 A12 : 0x071000c5 A13 : 0x00000000 A14 : 0x00000000 A15 : 0x00000000 SAR : 0x0000001d EXCCAUSE: 0x00000001 EXCVADDR: 0x00000000 LBEG : 0x400f1d56 LEND : 0x400f1d66 LCOUNT : 0x0000000f ELF file SHA256: 0000000000000000 Backtrace: 0x400f1d62:0x3ffafec0 0x400d692d:0x3ffafee0 0x400d3c08:0x3ffb0110 0x400d3f2d:0x3ffb0400 0x400d918a:0x3ffb1090 0x400d0fd1:0x3ffb1680 0x400d11bb:0x3ffb1b30 0x400da735:0x3ffb1fb0 0x400860ed:0x3ffb1fd0 Rebooting...
Az újraindulás az encrypt függvény futása alatt történik. Arduino ESP32 környezetet használok, a main.cpp-ben a CONFIG_ARDUINO_LOOP_STACK_SIZE 8192 van beállítva, 8k stack bőven elég kellene legyen ennek a futtatásához. És mondom, PC-n tökéletesen működik. Rejtély számomra, hogy ESP32-n miért nem. Valaki tudna segíteni?
A teljes kód ~200 sor, azt nem akarom ide bemásolni, csatolom (a szükséges Boneh-Franklin könyvtárakkal együtt).
Mutasd a teljes hozzászólást!
Csatolt állomány
A valgrind nevű program segíthet megtalálni a hibát.
Mutasd a teljes hozzászólást!
  • valgrind on esp32? - ESP32 Forum

    ebből a válaszból ikább a JTAC-re szavazok.
    Mutasd a teljes hozzászólást!
  • Természetes a desktop verziót kell valgrind-del futtatni, egyből kiderül, hogy a látszólag helyes lefutás mögött sok-sok apró disznóság van azért.
    Mutasd a teljes hozzászólást!
  • Köszönöm a segítséget mindkettőtöknek, megnéztem valgrind-del a PC-s verziót.
    Nem használtam soha valgrind-et, szóval nem értem teljesen amit látok, de vannak benne gyanús dolgok.
    Egyrészt van egy csomó Conditional jump or move depends on uninitialised value(s), bár azt hiszem ez a kisebb probléma. Viszont vannak olyanok is, hogy Invalid write of size 1, Invalid read of size 1.
    32 bytes in 1 blocks are still reachable in loss record 4 of 12, 5,376 bytes in 84 blocks are definitely lost in loss record 12 of 12, stb. Ezek milyen jellegű hibákra utalnak?
    Csatolom a teljes PC-s verziót, beleértve a g++-szal lefordított állományt is és a valgrind riportot (a main függvény a code.cpp-ben van). Megköszönném ha valaki tudna segíteni, hogy hol van elszúrva a dolog. Ebből ami saját kód, az csak a code.cpp, az összes többi ebből a library-ből van: miracl/core
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Helló!

    Próbáltad már ezt a stack trace decoder-t?
    me-no-dev/EspExceptionDecoder

    + ha jobban akarod struktúrálni a projektedet (clean code, Object-oriented), akkor érdemesebb a PlatformIO-val fejleszteni a kódot.
    Csak egy jótanács, ahhoz vannak még külön extension-ök is, és egész szép, értelmezhető stack trace-t kapsz console-on fájlnévvel, függvény nevével, és a sor számával.
    Egy példa, hogy milyen stack trace-t kapsz ha be van állítva rendesen a VSCode és a PlatformIO:
    T-Watch-2020 V3 TFT_eSPI fails in initDMA() function · Issue #126 · Xinyuan-LilyGO/TTGO_TWatch_Libra
    Mutasd a teljes hozzászólást!
  • nem néztem a kódodat. Csak azt akarom megkérdezni hogy az esp-nek van dedikált titkosító része, nem lenne célravezető azt használni?
    function block diagram

    pl: Example of using hardware AES 256 Crypto in CBC mode on the ESP32 using ESP-IDF
    Mutasd a teljes hozzászólást!
  • platformio.ini fájlba ezt kell tenni:
    monitor_speed = 115200
    monitor_filters = 
     default
     esp32_exception_decoder

    ... és a monitor console-ban megjelenik, hogy még milyen filtert vehetsz fel:
    --- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
    --- More details at http://bit.ly/pio-monitor-filters
     
    Please build project in debug configuration to get more details about an exception.
    See Build Configurations — PlatformIO 5.2.0a6 documentation
    Mutasd a teljes hozzászólást!
  • Kezdetnek a -g opció kellene, meg az include-ok nevét fixálni:

    $ diff -U0 utils.~h utils.h --- utils.~h 2021-04-18 15:36:54.000000000 +0200 +++ utils.h 2021-04-28 14:29:21.741200685 +0200 @@ -3 +3 @@ -#include "ECP_BN254.h" +#include "ecp_BN254.h" $ diff -U0 utils.~cpp utils.cpp --- utils.~cpp 2021-04-18 15:36:54.000000000 +0200 +++ utils.cpp 2021-04-28 14:28:35.131662876 +0200 @@ -3 +3 @@ -#include "FP_BN254.h" +#include "fp_BN254.h"
    Mutasd a teljes hozzászólást!
  • Amit küldtél PC program az bugos :(

    (gdb) r Starting program: C:\Users\XXX\Downloads\espdebug\bld2\esp.exe [New Thread 4736.0x1d28] [New Thread 4736.0x2d9c] [New Thread 4736.0x2628] Startloop Setup donewarning: HEAP[esp.exe]: warning: Heap block at 0000022097773C90 modified at 0000022097773CA1 past requested size of 1 Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffc7192a183 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\Windows\SYSTEM32\ntdll.dll (gdb) bt #0 0x00007ffc7192a183 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\Windows\SYSTEM32\ntdll.dll #1 0x00007ffc7192680f in ntdll!RtlZeroHeap () from C:\Windows\SYSTEM32\ntdll.dll #2 0x00007ffc718ecc82 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll #3 0x00007ffc71929031 in ntdll!RtlRegisterSecureMemoryCacheCallback () from C:\Windows\SYSTEM32\ntdll.dll #4 0x00007ffc71855cc1 in ntdll!RtlGetCurrentServiceSessionId () from C:\Windows\SYSTEM32\ntdll.dll #5 0x00007ffc71855b74 in ntdll!RtlGetCurrentServiceSessionId () from C:\Windows\SYSTEM32\ntdll.dll #6 0x00007ffc718547b1 in ntdll!RtlFreeHeap () from C:\Windows\SYSTEM32\ntdll.dll #7 0x00007ffc71089c9c in msvcrt!free () from C:\Windows\System32\msvcrt.dll #8 0x00007ff630f09b2e in loop () at ../code.cpp:193 #9 0x00007ff630f09b56 in main () at ../code.cpp:204

    code.cpp:193 -> free(cipherWBytes);
    Hol inicializáljuk?

    char messageBytes[100]; octet message = {0, sizeof(messageBytes), messageBytes}; char *cipherWBytes = (char *)calloc(message.len, sizeof(char));

    ajjaj :O

    (gdb) b code.cpp:173 Breakpoint 1 at 0x140009a1d: file ../code.cpp, line 173. (gdb) r Starting program: C:\Users\XXX\Downloads\espdebug\bld2\esp.exe [New Thread 11616.0x19cc] [New Thread 11616.0x353c] [New Thread 11616.0x11ec] Startloop Setup done Thread 1 hit Breakpoint 1, loop () at ../code.cpp:173 173 char *cipherWBytes = (char *)calloc(message.len, sizeof(char)); (gdb) p message $1 = {len = 0, max = 100, val = 0xe3c67ff270 "\001ô\177C\001"}

    calloc - ref

    If size is zero, the behavior is implementation defined (null pointer may be returned, or some non-null pointer may be returned that may not be used to access storage)
    Mutasd a teljes hozzászólást!
  • Itt az ideje, hogy a valgrind-et megszórjuk a --track-origins=yes opcióval, ilyen lesz az első hibaüzenete:

    Conditional jump or move depends on uninitialised value(s) at 0x40A1A6: BN254::FP_add(BN254::FP*, BN254::FP*, BN254::FP*) (fp_BN254.cpp:459) by 0x414754: BN254::FP2_neg(BN254::FP2*, BN254::FP2*) (fp2_BN254.cpp:164) by 0x407F30: BN254::ECP2_neg(BN254::ECP2*) (ecp2_BN254.cpp:317) by 0x407547: ECP2_select(BN254::ECP2*, BN254::ECP2*, int) (ecp2_BN254.cpp:86) by 0x409287: BN254::ECP2_mul4(BN254::ECP2*, BN254::ECP2*, int (*) [10]) (ecp2_BN254.cpp:633) by 0x40D8A6: BN254::PAIR_G2mul(BN254::ECP2*, int*) (pair_BN254.cpp:952) by 0x413B25: setup2(core::csprng*, BN254::ECP2*, core::octet*) (code.cpp:45) by 0x4141D7: loop() (code.cpp:161) by 0x414374: main (code.cpp:204) Uninitialised value was created by a stack allocation at 0x408D34: BN254::ECP2_mul4(BN254::ECP2*, BN254::ECP2*, int (*) [10]) (ecp2_BN254.cpp:562)
    Az utolsó sorból kiderül, hogy hol az 'ECP2_mul4' elején deklarált változók egyike inicializálatlan.

    void BN254::ECP2_mul4(ECP2 *P, ECP2 Q[4], BIG u[4]) { int i, j, k, nb, pb, bt; ECP2 T[8], W; BIG t[4], mt; sign8 w[NLEN_B256_28 * BASEBITS_B256_28 + 1]; sign8 s[NLEN_B256_28 * BASEBITS_B256_28 + 1];
    Mutasd a teljes hozzászólást!
  • Sacc/kb a 'W' okozza a gondot (abból gondolom, hogy ha 'memset'-elem a 'W'-t, akkor nem jön ez az üzenet). Egyébként lehet, hogy azzal kellene kezdeni, hogy innen frissíted a programodat: miracl/core
    Mutasd a teljes hozzászólást!
  • If size is zero, the behavior is implementation defined

    De a size az jelen esetben sizeof(char), ami nem nulla, szóval ez miért rossz?
    Mutasd a teljes hozzászólást!
  • Javítottam az utils.h-t illetve az utils.cpp-t, plusz néhány helyen dinamikos foglalással foglalt memória nem lett felszabadítva, ezeket is megcsináltam. Legalább ez a része rendben van.

    ==220== HEAP SUMMARY: ==220== in use at exit: 0 bytes in 0 blocks ==220== total heap usage: 100 allocs, 100 frees, 4,032 bytes allocated ==220== ==220== All heap blocks were freed -- no leaks are possible
    Mindenesetre megpróbálom frissítgetni a fájlokat, hátha segít.
    Mutasd a teljes hozzászólást!
  • message.len = 0
    Az akkor kap értelmes értéket, ha azzal az utána lévő függvénnyel beleolvasod a szövegkonstansod.
    Mutasd a teljes hozzászólást!
  • A két szám közül a másik a nulla, a message.len. Talán ez lenne jobb (a sizeof(char) definíció szerint 1):

    char *cipherWBytes = (char *)calloc(message.max, 1);
    Mutasd a teljes hozzászólást!
Címkék
abcd