elf: Fix for mismatched app ELF file not detected. (IDFGH-9855)

[projectgus]

The check that the app ELF file SHA256 matches the one stored in the core dump would never fail, leading to gdb loading the wrong ELF file and either crashing or producing misleading debug information.

Specifics:

The note_sec.name field was incorrectly read back as b'ESP_CORE_DUMP_INFO\x00E', because the namesz length includes the terminating NUL byte and possible junk padding bytes:
https://github.com/espressif/esp-idf/blob/master/components/espcoredump/src/core_dump_elf.c#L212

In addition, as note_sec.name is a bytes object Python 3 would have never successfully compared it with a string.

[projectgus]

If possible, I'd appreciate a backport to the ESP-IDF release/v4.4 branch as this is where I stumbled across it.

I hope you folks are all doing well. :)

[projectgus]

Hmm OK, this now fails for another reason. The core dump I have only contains the first 16 characters of the ELF SHA, for some reason:

00006f60  00 00 00 00 00 00 00 00  14 00 00 00 48 00 00 00  |............H...|
00006f70  4a 20 00 00 45 53 50 5f  43 4f 52 45 5f 44 55 4d  |J ..ESP_CORE_DUM|
00006f80  50 5f 49 4e 46 4f 00 45  00 01 09 00 63 36 36 34  |P_INFO.E....c664|
00006f90  66 66 38 61 61 66 39 31  37 32 31 39 00 00 00 00  |ff8aaf917219....|
00006fa0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The remaining bytes are there, but all zero.

EDIT:

    config APP_RETRIEVE_LEN_ELF_SHA
        int "The length of APP ELF SHA is stored in RAM(chars)"
        default 16

ah yeah,that'll do it.

[igrr]

Hey @projectgus, thanks for the fix!

> The remaining bytes are there, but all zero.

This could be related to CONFIG_APP_RETRIEVE_LEN_ELF_SHA setting, could you please check how the app is configured?

(I now see your updated comment)

[projectgus]

@igrr yeah, I just remembered/saw this now as well!

So I guess the Python code needs to compare all the bytes in the core dump file, except for any trailing 00 bytes?

[igrr]

I think so, yes... Ideally we should have also recorded the length of the truncated SHA256 there, but alas.

Over here we use in to check for the SHA256 match:

https://github.com/espressif/esp-idf-monitor/blob/6a633628a380437bf3cb4a226ac1bfdec79eed5b/esp_idf_monitor/base/serial_handler.py#L165-L182

which is not very precise, but i guess the likelihood that the truncated SHA256 is a substring of a different SHA256 is pretty low in practice.

[projectgus]

Thanks for the explanation, @igrr. Have pushed some fixes that seem to allow esp-coredump.py to detect correctly if the APP ELF matches or not.

This fix may potentially save a lot of hair-pulling about "nonsense" core dump debug output!

[igrr]

@projectgus I have done the backport of your fixes to IDF release/v4.4, but it turned out the ELF & coredump files used in our CI actually didn't have matching SHA256. (Which is understandable, since these were just "dummy" ELF files, but it never occurred to me that such combination is not supposed to work.)
We'll need a bit of time to fix this test issue and will merge the backport once that is done.

[projectgus]

No worries @igrr, thanks for the update!

[dobairoland]

Thank you @projectgus for the contribution. It revealed a couple of issues in our tests which had to fixed first. That is why this took long to solve. Now it is merged to the v4.4 release branch and should be available soon. Probably it will be released in v4.4.6.

Here are the commits in v4.4 for future reference:

• espressif/esp-idf@e32cca2
• espressif/esp-idf@76e1212
• espressif/esp-idf@2d26ace

[projectgus]

No worries at all @dobairoland, thanks for the update!