[Question] If an OTA is interrupted, will the bootloader detect the invalid image? always? (IDFGH-10921)

[chipweinberger]

General issue report

I have read the documentation here:

• https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/bootloader.html
• https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/ota.html
• https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v1.html

Question:

If the main OTA update did not complete (i.e. due to power loss), I want to:

1. make sure my device bootloader always detects that the OTA was incomplete (i.e. invalid app)
2. boot into a different 'firmware update' app instead

I have a custom bootloader, so number '2' is no issue, I'm concerned about how reliable number '1' is. Will the bootloader detect the invalid image? always?

• do I need to enable secure boot to reliably detect incomplete OTA?
• or maybe I need to implement a "OTA IS IN PROGRESS" nonvolatile flag myself?

[chipweinberger]

The relevant code seems to be in image_load, as part of the bootloader.

esp-idf/components/bootloader_support/src/esp_image_format.c

Line 126 in 3247253

static esp_err_t image_load(esp_image_load_mode_t mode, const esp_partition_pos_t *part, esp_image_metadata_t *data)

It does appear to calculate a checksum of the entire app, so incomplete OTA should always be detected, perhaps.

edit: the checksum appears to be a single byte? why so small?

[chipweinberger]

It looks like in non-secure mode we also check the appended SHA256

        // No secure boot, but SHA-256 can be appended for basic corruption detection
        if (sha_handle != NULL && !esp_cpu_dbgr_is_attached()) {
            err = verify_simple_hash(sha_handle, data);
            sha_handle = NULL; // calling verify_simple_hash finishes sha_handle
        }

But I do not understand this comment, which seems to contradict the above statement. Edit: nevermind this comment appears to be about checking the SHA256 of the bootloader itself, not the app

    // (For non-secure boot, we don't verify any SHA-256 hash appended to the bootloader because
    // esptool.py may have rewritten the header - rely on esptool.py having verified the bootloader at flashing time, instead.)
    verify_sha = (part->offset != ESP_BOOTLOADER_OFFSET) && do_verify;

---

So in summary, it seems we should always (*) detect an incomplete OTA update during the next boot. Can anyone confirm?

(*) apart from SHA256 hash collisions (i.e. extremely improbable)

[mahavirj]

@chipweinberger

• First of all, if the the OTA update process is interrupted in between then I believe the application won't call the API esp_ota_set_boot_partition (?). Even if the application calls this API to set next boot partition then the API first verifies the image integrity and then only updates the otadata partition.
• Yes, the application image integrity check happens during the bootup. Typically its the SHA256 checksum, provided the image has the hash_appended field set in the image header. Legacy images used to have only the CRC check (very old IDF releases). Please refer to the documentation regarding the format here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/app_image_format.html
• In-fact the application integrity check consumes most of the boot-up time and hence we have a config option BOOTLOADER_SKIP_VALIDATE_ON_POWER_ON to disable the check (if required)
• 2nd stage bootloader workflow is briefly documented here: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/startup.html#second-stage-bootloader

Hope this helps!

[chipweinberger]

@mahavirj thanks it does help!

First of all, if the the OTA update process is interrupted in between then I believe the application won't call the API esp_ota_set_boot_partition

I have a weird setup with a "main" app and "firmware update" app. I always reset otadata back to "main" after boot. So it's possible I try to boot an incomplete image.

this is why i wanted to confirm the validity check is reliable :)