SHA-256 for running partition all zero?

[LaWi14]

Following the native OTA example I try to output the SHA-256 for partition table, bootloader and firmware like this:

Code: Select all

// get sha256 digest for the partition table
    partition.address = ESP_PARTITION_TABLE_OFFSET;
    partition.size = ESP_PARTITION_TABLE_MAX_LEN;
    partition.type = ESP_PARTITION_TYPE_DATA;
    esp_partition_get_sha256(&partition, sha_256);
    print_sha256(sha_256, "SHA-256 for the partition table: ");

    // get sha256 digest for bootloader
    partition.address = ESP_BOOTLOADER_OFFSET;
    partition.size = ESP_PARTITION_TABLE_OFFSET;
    partition.type = ESP_PARTITION_TYPE_APP;
    esp_partition_get_sha256(&partition, sha_256);
    print_sha256(sha_256, "SHA-256 for bootloader: ");

    const esp_partition_t *running = esp_ota_get_running_partition();
    err = esp_partition_get_sha256(running, sha_256);
    if (err == ESP_OK)
    {
        print_sha256(sha_256, "SHA-256 for current firmware: ");
    }
    else
    {
        ESP_LOGW(TAG, "Failed to get SHA-256 for current firmware: %s", esp_err_to_name(err));
    }

But I get always all zero for the firmware:

Code: Select all

I (569) ota_work_example: SHA-256 for the partition table: : 1da6115f8cb1194eca355efc369bc41453a044aedc8937666c307d7ee9db3f92
I (579) boot_comm: chip revision: 1, min. application chip revision: 0
I (609) ota_work_example: SHA-256 for bootloader: : 9dc4f10c8b78988b243757cbc9bb7e1a8164cb7cc7119f129c8a229094b402cc
I (619) boot_comm: chip revision: 1, min. application chip revision: 0
I (1229) ota_work_example: SHA-256 for current firmware: : 0000000000000000000000000000000000000000000000000000000000000000

Is this to be expected? It does not change even after multiple successful OTA updates.

Thomas

[ESP_Angus]

Hi Thomas,

What ESP-IDF version do you have? And what's the return value from calling esp_partition_get_sha256()?

A list of possible return values is here: https://docs.espressif.com/projects/esp ... tP7uint8_t

There are some differences for getting SHA-256 of an app partition, mostly that the app is verified and if a SHA hash is appended as part of the .bin file, this SHA is returned instead of one calculated over the bytes of the image. More details at above link.

If the function is failing, the task is to figure out why (as obviously the running app partition should hold a valid app). If the function is succeeding, this is probably a bug.


Angus

[LaWi14]

Hi Angus,
I am using ESP-IDF v4.1-dev-815-ga45e99853. As you can see from my code snippet, the return value is ESP_OK.

I looked up the definition of esp_partition_get_sha256(), which calls bootloader_common_get_sha256_of_partition(). There it returns from a call to esp_image_verify() with data.image.hash_appended set, but with an empty data.image_digest. Digging further I found that a function image_load() is called, which is supposed to return the image digest (but returns empty data).
Last thing I checked is an error-free return from a call to err = verify_simple_hash(sha_handle, data);


Thomas

[chegewara]

Few months ago ive been doing OTA over BLE example and sha has been working with master (it was v4.0), but now i am trying to do the same with PlatformIO esp-idf framework and this is what i found:

Code: Select all

[0;32mI (440) cpu_start: Application information:␛[0m
␛[0;32mI (445) cpu_start: Project name:     platformio factory app␛[0m
␛[0;32mI (451) cpu_start: App version:      1.0.0␛[0m
␛[0;32mI (456) cpu_start: Compile time:     Nov 26 2019 16:33:35␛[0m
␛[0;32mI (462) cpu_start: ELF file SHA256:  0000000000000000...␛[0m
␛[0;32mI (468) cpu_start: ESP-IDF:          3.30300.190916␛[0m

SHA256 is all 0s after restart.

[LaWi14]

To continue my test: "Last thing I checked is an error-free return from a call to err = verify_simple_hash(sha_handle, data);" --> this function even debug-prints a non-null hash:

Code: Select all

D (1794) boot: Calculated hash: 3954b6030aa3f19e7aeb7acbd93ed974e4ef5e8d5865f366e101047a079649fa

But it does not make it to the caller as in the if (verify_sha) branch of the code no calculated or read-out hash is copied to data->image_digest (as is done in the else branch) (lines 230 ... 270 of esp_image_format.c).

Thomas

[WiFive]

Your analysis looks correct, neither verify_secure_boot_signature nor verify_simple_hash sets the metadata hash.

[LaWi14]

I compared the code of the current esp_image_format.c with an older version (pulled from git on October, 7th). And the older version has the copying of the hash to the image_digest (the block "if (data->image.hash_appended)" ) AFTER the "if (verify_sha) { ... } else { ...}" block, while the current version has it IN the "else" block of "verify_sha".
Moving the copying from the "else" branch after the if/else construct where it was earlier returns the hash to the callers.

But I do not understand the code well enough as to know if there are any side effects of this. Maybe somebody more familiar with this code can check?

Thomas

[LaWi14]

To follow up myself: the mentioned change went in with the commit by "projectgus" on 16 Sep. See the diff for esp_image_format.c, lines 217-222 (OLD) / 227-231 (NEW) and 224-232 (OLD) / 233-244 (NEW): "if (data->image.hash_appended) {...}" has been moved into the else branch by this.

[ESP_Angus]

Thanks for the analysis and all the details. It does look like this was broken in master during the process of adding ESP32-S2 support.

Will fix ASAP.

[WiFive]

Thanks for the analysis and all the details. It does look like this was broken in master during the process of adding ESP32-S2 support.

Will fix ASAP.

Should the freshly calculated hash be returned when available instead of always returning the recorded hash? Either way it should be done from inside the verify functions because the hashes are already available there.