Secure Boot V2 failure: Sig block 0 invalid: Image digest does not match (IDFGH-6787) #8414
Comments
github-actions
bot
changed the title
|
@badevos Thanks for reporting. Would you please help provide more details as suggested in the issue template? Information like elf, sdk configuration, backtrace, log outputs, commit ID, hardware and etc. would help us debug further. Thanks. |
|
Sorry, my fault: I did prepare this, but my details are gone ... Environment
Problem DescriptionI have a configuration and some scripts to activate Secure Boot and Flash Encryption and burn the relevant fuses from the bootloader (first run). This does work on the devkit, but does not on our own board. The digest calculation of the app image does not match the one from the bootloader on our own board. Expected BehaviorBootloader to run and execute exactly the same on both boards. Actual BehaviorThe digest calculation of the app image does not match the one from the bootloader on our own board. Steps to reproduceI have made some scripts (see attachements). Those are shell scripts, but I renamed them to .txt to get them uploaded here. They should be ran in this order:
The flash memory is connected as follows: Code to reproduce this issueI have no specific code, as I rely on the bootloader code. Debug LogsOther items if possiblemy |
|
Some more info: I tried by manually burning the digest on both devkit and proprietary board:
This is a bootlog with debug info for the failing case: |
|
+1 I am using ESP32-DevkitC-VE (Wrover Module) with 8MB Flash. If I burn the digest using : espefuse.py --port COM6 burn_key_digest X:\secure_boot_signing_key.pem, "Sig block 0 invalid: Image digest does not match" If I don't burn the digest manually, I get similar message as you are getting in your first post. For far bricked 2 devkits in the process. |
|
@badevos - Did you sign your Partition-table.bin also ? |
|
Hi, |
|
@mahavirj already confirmed that partition does not need to be signed in Secure Boot V2. (https://esp32.com/viewtopic.php?f=13&t=26199). I was merely trying to understand why line is showing (after partition table) I am also getting similar result on my end. I cant understand why the hash results are different:
|
|
Meanwhile I tried to read back the content of the memory and dump it to a file. This fails as well. For example to read back the bootloader, I tried: esptool.py dump_mem 0x1000 0xd000 ./bootloader_dump.bin
esptool.py v3.2-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 40:91:51:20:8d:c8
Uploading stub...
Running stub...
Stub running...
A fatal error occurred: Invalid head of packet (0x46): Possible serial noise or corruption.I also tried with This error I do get on both devkit and proprietary board. Attached is the output of As mentioned, the system does work on the devkit in my case, hence the secure boot key is burned as well as the flash encryption key on this board. |
|
I noticed ABS_DONE_1 is not burnt in your proprietary board. But be careful, if you burn it as 1 manually, you might not be able to go back! Block 2 is burnt in both cases. Did they automatically get burnt or did you burn them manually ? |
|
Block 2 is burned automatically in the devkit and manually in the proprietary board. Automatic burning in the bootloader occurs after successfull verification of the application signature, which is a phase I never reached on proprietary board off course. |
|
Hi @badevos! |
|
Here is the method I tried seeing your post : Error I get : I am using the following command to sign : |
|
@KonstantinKondrashov : Do you think there is a problem with espsecure.py signing tool ? Does it matter if I am using |
|
Here is what I did again :
For reading again : |
|
As I understand from summary and information shared by @badevos, this issue is happening only on custom hardware. Is that case with you as well? Note: I am going through all logs, I will share my findings soon. |
One thing to add: Bootloader first does signature verification for firmware and then for its own image. In this case, from logs above we can see that bootloader signature verification has failed. So, this is definitely an issue with bootloader image itself. Do you use (signed) bootloader binary as generated by build system? Also please confirm if same binary works on Espressif Devkit but fails on your hardware? |
|
@mahavirj No. I am using ESP32-DevkitC-VE V4 (WROVER-E with 8 MB Flash) directly made by Espressif. I am manually signing the bootloader.bin after the build succeeds by using : Then I am merging the bin using : Then I am encrypting the data: Then flashing : Just to further clarify, I have unchecked the option of 'Sign Binaries during build' |
I would request to file new issue in that case. Original report in this issue is specific to custom hardware only, as I understand it.
It is possible that Have you set same flash configuration during build as well? Can you please share your log during |
|
@mahavirj I have verified that the menuconfig also has 'qout', 80m and 8MB in settings which is same as the command I am executing I had tried flashing with dio mode @ 40m also but result is the same. |
|
Hi, I first followed the suggestions from @KonstantinKondrashov to read back some images from the flash. Also @mahavirj is questioning the correctness of the bootloader, which is relevant for my furthern analysis. The difference in my case for both boards it the size of the flash memory. This has been set to 8MB in my case, in order to be able preparing a build that would run on the devkit. Yet my own board only has 4MB of flash. And I used config option: If this option is set, flashing the project will automatically detect
the flash size of the target chip and update the bootloader image
before it is flashed.I converted the binary files (produced by the build system and read back from the flash) to hex to capture 'some' differences. The comparison reveals that the binary images are actually equal, except for a single byte, in the very first line. The fourth byte is 0x30 vs. 0x20, meaning that they are not equal, and signature verification should fail for that reason. A side question I have, I did not know the exact size of the bootloader, so I did read the complete bootloader partition, which is bigger than what was originally flashed. I can imagine that the size of the file provided to I assume that disabling @gb-123-git: would it be an option on your side to adjust the flash size according to your board and disable Feedback? |
|
@badevos UPDATE : I think there was a similar issue #6050 but it was closed and applied to IDF 4.3 & IDF 4.2. Do you think it could have cropped back up in IDF v4.4 ? |
The file size for this
Yes, Hash is calculated over the whole image including this header up to end including padding + checksum.
Yes, you need to specify the certain flash size |
This makes sense now. If we compare this data against image header then this field corresponds to flash size (4-bit field) and this has been updated (see I would recommend using |
|
I can confirm my ESP32 has started to work. The header size seemed to be an issue as it was getting over-riden by a different value while flashing bootloader. @badevos - You can safely try flashing your board. In case you are flashing/building using PlatformIO, your value in menuconfig / sdkconfig will NOT work. It will be over-ridden by platform.ini or your boardconfig.json Also note : The Flash mode in sdkconfig refers to the second bootloader. The one you flash with |
|
@mahavirj @KonstantinKondrashov Thanks for your support! Thanks for posting this issue. It has given me a lot of insight on how this works.. I am still here to help you out in case you need it. |
|
@gb-123-git: thanks for your confirmation. I don't use platform-io, yet I understand the confusion due to Your remarks regarding 'qio'/'dio' doesn't ring a bell with me. Unfortunately I have a priority change and I can't test this further on short term. Nevertheless within a few weeks I have to prepare production scripts and pick this up again then. Sorry for the inconvenience. |
|
My job is already done and I have successfully implemented the secure rom v2 at my end. I just wanted to help you fix your board as well. :) |
|
Further update on this issue:
I will close this issue for now. Please feel free to comment here in case you would like to keep this issue open or any further concerns. |
espressif-bot
added
Resolution: Done
----------------------------- Delete below -----------------------------
Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.
INSTRUCTIONS
Before submitting a new issue, please follow the checklist and try to find the answer.
If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.
IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.
----------------------------- Delete above -----------------------------
Environment
git describe --tagsto find it):// v3.2-dev-1148-g96cd3b75c
xtensa-esp32-elf-gcc --versionto find it):// 1.22.0-80-g6c4433a
Problem Description
//Detailed problem description goes here.
Expected Behavior
Actual Behavior
Steps to reproduce
// If possible, attach a picture of your setup/wiring here.
Code to reproduce this issue
// If your code is longer than 30 lines, GIST is preferred.
Debug Logs
Other items if possible
buildfolder (note this may contain all the code details and symbols of your project.)The text was updated successfully, but these errors were encountered: