ESP32 Forum

ESP32 Official Forum
http://esp32.io/

Crash when esp_secure_boot_verify_signature

http://esp32.io/viewtopic.php?f=13&t=9506

Page 1 of 1

Crash when esp_secure_boot_verify_signature

Posted: Mon Mar 04, 2019 6:30 am
by enos2237
Hi, everybody

My SDK version: e9a764d9a5d4a01a6bca64d8304340b8c9f1a2c6

I am trying secure boot and OTA.
And I find esp32 would crash at esp_https_ota() when my OTA image over 900K and secure boot is on.
Then I find it always crash at esp_sha().

Then i tried SDK version v3.2-beta1: a4357aed91c8a03384691df91b93a6f455371e54, and it works fine.


Please let me know if this is a bug or I do something stupid.
Thanks for your time.

Re: Crash when esp_secure_boot_verify_signature

Posted: Tue Mar 05, 2019 12:57 am
by ESP_Angus
Hi enos2237,

If v3.2-beta1 works but beta3 crashes, this is probably a bug. Can you please post a full stack trace of the crash?


Angus

Re: Crash when esp_secure_boot_verify_signature

Posted: Tue Mar 05, 2019 9:15 am
by enos2237
Hi Angus,

Backtrace

Code: Select all

Guru Meditation Error: Core  1 panic'ed (Interrupt wdt timeout on CPU1)
Core 1 register dump:
PC      : 0x4008131c  PS      : 0x00060034  A0      : 0x8011f969  A1      : 0x3ffdced0  
A2      : 0x00000001  A3      : 0x00060023  A4      : 0x3f4fbe40  A5      : 0x00000200  
A6      : 0x00000000  A7      : 0x00000010  A8      : 0x00000000  A9      : 0x00000001  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00060023  A13     : 0x00000020  
A14     : 0xffffffe0  A15     : 0x3df03df0  SAR     : 0x00000000  EXCCAUSE: 0x00000006  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

Backtrace: 0x4008131c:0x3ffdced0 0x4011f966:0x3ffdcef0 0x400ecb34:0x3ffdcf30 0x400ec0eb:0x3ffdcf80 0x40154af5:0x3ffdd0b0 0x400d6f3e:0x3ffdd0f0 0x40092c8d:0x3ffdd1b0
Coredump

Code: Select all

===============================================================
==================== ESP32 CORE DUMP START ====================

================== CURRENT THREAD REGISTERS ===================
/Volumes/build/idf/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: struct value *value_of_register_lazy(struct frame_info *, int): Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/Volumes/build/idf/crosstool-NG/.build/src/gdb-7.10/gdb/findvar.c:290: internal-error: struct value *value_of_register_lazy(struct frame_info *, int): Assertion `frame_id_p (get_frame_id (frame))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
yGDB exited (None / None)!
Problem occured! GDB exited, restart it.
Reading symbols from t4_factory.elf...done.
[New <main task>]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[New process 5]
[New process 6]
[New process 7]
[New process 8]
[New process 9]
[New process 10]
[New process 11]
[New process 12]
[New process 13]
[New process 14]
[New process 15]
[New process 16]
[Current thread is 1 (<main task>)]

==================== CURRENT THREAD STACK =====================
#-1 0x4005c2f4 in ?? ()
Backtrace stopped: Cannot access memory at address 0x4005c2f4

======================== THREADS INFO =========================
  Id   Target Id         Frame 
  17   process 16        0x40093695 in xQueueGenericReceive (xQueue=0x3ffcced4, pvBuffer=0x3ffce130, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  16   process 15        0x40093695 in xQueueGenericReceive (xQueue=0x3ffb7ea0, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  15   process 14        0x40093695 in xQueueGenericReceive (xQueue=0x3ffb4668, pvBuffer=0x3ffb5610, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  14   process 13        0x40093695 in xQueueGenericReceive (xQueue=0x3ffaff64, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  13   process 12        0x40093695 in xQueueGenericReceive (xQueue=0x3ffce428, pvBuffer=0x3ffcf850, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  12   process 11        0x40093695 in xQueueGenericReceive (xQueue=0x3ffb7a48, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  11   process 10        0x40093695 in xQueueGenericReceive (xQueue=0x3ffd9e9c, pvBuffer=0x0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  10   process 9         0x40093695 in xQueueGenericReceive (xQueue=0x3ffd7ad4, pvBuffer=0x3ffd8f90, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  9    process 8         0x40093695 in xQueueGenericReceive (xQueue=0x3ffd6c04, pvBuffer=0x3ffd75b0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  8    process 7         0x40093695 in xQueueGenericReceive (xQueue=0x3ffb5bac, pvBuffer=0x3ffd59e0, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  7    process 6         0x40093695 in xQueueGenericReceive (xQueue=0x3ffd5c00, pvBuffer=0x3ffd6820, xTicksToWait=4294967295, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  6    process 5         0x400952d4 in prvProcessTimerOrBlockTask (xNextExpireTime=<optimized out>, xListWasEmpty=<optimized out>) at /Users/enos/esp/esp-idf/components/freertos/timers.c:588
  5    process 4         0x40093695 in xQueueGenericReceive (xQueue=0x3ffbd0f8, pvBuffer=0x3ffdc060, xTicksToWait=10, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  4    process 3         0x40093695 in xQueueGenericReceive (xQueue=0x3ffcc1ec, pvBuffer=0x3ffccc00, xTicksToWait=5, xJustPeeking=0) at /Users/enos/esp/esp-idf/components/freertos/queue.c:1591
  3    process 2         0x4018d13a in esp_pm_impl_waiti () at /Users/enos/esp/esp-idf/components/esp32/pm_esp32.c:487
  2    process 1         0x4000bff0 in ?? ()
* 1    <main task>       0x4005c2f4 in ?? ()

======================= ALL MEMORY REGIONS ========================
Name   Address   Size   Attrs
.rtc.text 0x400c0000 0x0 RW  
.rtc.dummy 0x3ff80000 0x0 RW  
.rtc.force_fast 0x3ff80000 0x0 RW  
.rtc_noinit 0x50000000 0x0 RW  
.rtc.force_slow 0x50000000 0x0 RW  
.iram0.vectors 0x40080000 0x400 R XA
.iram0.text 0x40080400 0x16010 RWXA
.dram0.data 0x3ffbdb60 0x351c RW A
.noinit 0x3ffc107c 0x0 RW  
.flash.rodata 0x3f400020 0x2eabc RW A
.flash.text 0x400d0018 0xbfca8 R XA
.coredump.tasks.data 0x3ffdd688 0x164 RW 
.coredump.tasks.data 0x3ffdd230 0x450 RW 
.coredump.tasks.data 0x3ffbc458 0x164 RW 
.coredump.tasks.data 0x3ffbc250 0x200 RW 
.coredump.tasks.data 0x3ffbbcec 0x164 RW 
.coredump.tasks.data 0x3ffbbb40 0x1a4 RW 
.coredump.tasks.data 0x3ffcccc4 0x164 RW 
.coredump.tasks.data 0x3ffccab0 0x20c RW 
.coredump.tasks.data 0x3ffdc11c 0x164 RW 
.coredump.tasks.data 0x3ffdbf60 0x1b4 RW 
.coredump.tasks.data 0x3ffbceb8 0x164 RW 
.coredump.tasks.data 0x3ffbcd10 0x1a0 RW 
.coredump.tasks.data 0x3ffd68d8 0x164 RW 
.coredump.tasks.data 0x3ffd6720 0x1b0 RW 
.coredump.tasks.data 0x3ffd5a98 0x164 RW 
.coredump.tasks.data 0x3ffd58e0 0x1b0 RW 
.coredump.tasks.data 0x3ffd766c 0x164 RW 
.coredump.tasks.data 0x3ffd74b0 0x1b4 RW 
.coredump.tasks.data 0x3ffd904c 0x164 RW 
.coredump.tasks.data 0x3ffd8e90 0x1b4 RW 
.coredump.tasks.data 0x3ffdb5b0 0x164 RW 
.coredump.tasks.data 0x3ffdb3b0 0x1f8 RW 
.coredump.tasks.data 0x3ffb9a3c 0x164 RW 
.coredump.tasks.data 0x3ffb7cf0 0x1a8 RW 
.coredump.tasks.data 0x3ffcf914 0x164 RW 
.coredump.tasks.data 0x3ffcf720 0x1ec RW 
.coredump.tasks.data 0x3ffb7780 0x164 RW 
.coredump.tasks.data 0x3ffb75d0 0x1a8 RW 
.coredump.tasks.data 0x3ffb56c8 0x164 RW 
.coredump.tasks.data 0x3ffb54f0 0x1d0 RW 
.coredump.tasks.data 0x3ffb9fa8 0x164 RW 
.coredump.tasks.data 0x3ffb9e00 0x1a0 RW 
.coredump.tasks.data 0x3ffce214 0x164 RW 
.coredump.tasks.data 0x3ffce030 0x1dc RW 

===================== ESP32 CORE DUMP END =====================
===============================================================
And I modified esp_sha() function in components/esp32/hwcrypto/sha.c like this:

Code: Select all

void esp_sha(esp_sha_type sha_type, const unsigned char *input, size_t ilen, unsigned char *output)
{
    size_t block_len = block_length(sha_type);

    esp_sha_lock_engine(sha_type);

    SHA_CTX ctx;
    ets_sha_init(&ctx);
    while(ilen > 0) {
        size_t chunk_len = (ilen > block_len) ? block_len : ilen;
        esp_sha_lock_memory_block();
        esp_sha_wait_idle();
        DPORT_STALL_OTHER_CPU_START();
        {
            // This SHA ROM function reads DPORT regs
            ets_sha_update(&ctx, sha_type, input, chunk_len * 8);
        }
        DPORT_STALL_OTHER_CPU_END();
        esp_sha_unlock_memory_block();
        input += chunk_len;
        ilen -= chunk_len;
    }
    esp_sha_lock_memory_block();
    esp_sha_wait_idle();
    DPORT_STALL_OTHER_CPU_START();
    {
        ets_sha_finish(&ctx, sha_type, output);
    }
    DPORT_STALL_OTHER_CPU_END();
    esp_sha_unlock_memory_block();

    esp_sha_unlock_engine(sha_type);
}
It works.

Re: Crash when esp_secure_boot_verify_signature

Posted: Fri Mar 08, 2019 7:28 am
by ESP_Angus
Hi enos2237,

Thanks for letting us know about this. A fix for esp_sha() has been committed and will be merged to master soon. It's almost identical to your fix (the only change is a very small optimisation that we call esp_wait_for_idle() twice, once before taking the memory block lock and once after, to minimise the amount of time spent busy-waiting with the lock.)

Actually, I made another change as well - we'll switch the signature verification to calling the mbedTLS SHA API instead of esp_sha(). This API is probably already compiled in on most non-trivial firmwares, so it may reduce the file size of large binaries by a very small amount. This second change will be in ESP-IDF v3.3 or v4.0 but may not be backported to v3.2.

Angus
All times are UTC
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/