Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
-
- Posts: 6
- Joined: Wed Aug 19, 2020 4:02 pm
Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hi,
I did the following steps to perform secure boot and flash encryption.
ESP IDF Version: release-v3.2
1. Generate secure boot signing key and flash encryption key.
2. Burn flash encryption key.
3. Enabled secure boot(One time flash) and flash encryption from the menuconfig
4. Build binary
5. Flash the binary using flash download tool v3.6.4.
Reset the chip then the chip is continuously rebooting with flash read err, 1000.
Checked eFuse register summary,
- Both BLK1 and BLK2 registers are burnt.
- FLASH_CRYPT_CNT is 0x1.
- ABS_DONE_0 is 0x1
I tried to read flash and compare it with plaintext binary, from that I found partitions are not encrypted yet.
Then I read Flash encryption document again for disabling flash encryption.
Below steps performed to recover chip,
1. Disable flash encryption.
./espefuse.py --baud 115200 --port COM burn_efuse FLASH_CRYPT_CNT
2. check eFuse summary and found FLASH_CRYPT_CNT 0x2
3. Load plaintext binaries(Bootloader, app, and partitions).
Note: Used the same binary which I have loaded the first time.(Secure boot(One time flash) + Flash Encryption).
4. Still facing the same error flash read err, 1000.
Did I miss any steps?
I did the following steps to perform secure boot and flash encryption.
ESP IDF Version: release-v3.2
1. Generate secure boot signing key and flash encryption key.
2. Burn flash encryption key.
3. Enabled secure boot(One time flash) and flash encryption from the menuconfig
4. Build binary
5. Flash the binary using flash download tool v3.6.4.
Reset the chip then the chip is continuously rebooting with flash read err, 1000.
Checked eFuse register summary,
- Both BLK1 and BLK2 registers are burnt.
- FLASH_CRYPT_CNT is 0x1.
- ABS_DONE_0 is 0x1
I tried to read flash and compare it with plaintext binary, from that I found partitions are not encrypted yet.
Then I read Flash encryption document again for disabling flash encryption.
Below steps performed to recover chip,
1. Disable flash encryption.
./espefuse.py --baud 115200 --port COM burn_efuse FLASH_CRYPT_CNT
2. check eFuse summary and found FLASH_CRYPT_CNT 0x2
3. Load plaintext binaries(Bootloader, app, and partitions).
Note: Used the same binary which I have loaded the first time.(Secure boot(One time flash) + Flash Encryption).
4. Still facing the same error flash read err, 1000.
Did I miss any steps?
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Moderator's note: edit the topic title for issue tracking, thanks for reporting.
-
- Posts: 6
- Joined: Wed Aug 19, 2020 4:02 pm
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hi,
Any update on this issue?
Any update on this issue?
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hello Espressif Team,
Would you please check issue which has been generated Nikunj Patel which whom i am working? As we have critical for that and faced issue into at-least 5 modules out of 25 modules.
We have tried to disable flash encryption using below method but still it didn't work.
https://docs.espressif.com/projects/esp ... ption.html
Let me know if need anything else from our end.
Would you please check issue which has been generated Nikunj Patel which whom i am working? As we have critical for that and faced issue into at-least 5 modules out of 25 modules.
We have tried to disable flash encryption using below method but still it didn't work.
https://docs.espressif.com/projects/esp ... ption.html
Let me know if need anything else from our end.
Regards,
Ritesh Prajapati
Ritesh Prajapati
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hello Espressif Team,
Any update regarding this issue? or let us know if need anything else from our end.
Any update regarding this issue? or let us know if need anything else from our end.
Regards,
Ritesh Prajapati
Ritesh Prajapati
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
If the same flashing process is failing on only a few modules it sounds like a hardware issueat-least 5 modules out of 25 modules
-
- Posts: 6
- Joined: Wed Aug 19, 2020 4:02 pm
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hi WiFive,
Thanks for the response.
Is there any way we can recover it?
Is there any way to get idea what is the hardware issue?
Thanks for the response.
Is there any way we can recover it?
Is there any way to get idea what is the hardware issue?
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hello,
What kind of Hardware issue are you mentioning? means ESP32 Module completely damaged? can you please clarify for same from your end?
Regards,
Ritesh Prajapati
Ritesh Prajapati
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hi Nikunj,
Without seeing the boot logs it's hard to tell exactly what happened. Normally on first boot the bootloader would not burn FLASH_CRYPT_CNT to 0x1 until after it encrypts the bootloader all partitions, so I can't provide an explanation for how this efuse was burned but the partitions were still plaintext. Is it possible the flash chip has enabled hardware write protection somehow? Or that the FLASH_CRYPT_CNT efuse had been burned already before flashing of the plaintext firmware was done?
If FLASH_CRYPT_CNT value is 0x2 then it should be possible to boot a plaintext bootloader. The "flash read err, 1000." indicates that the bootloader header at offset 0x1000 in the flash is invalid. Can you read the flash back and confirm that this part of the bootloader is not corrupted?
Agree with WiFive's suggestion that an intermittent failure on only some boards with the same provisioning process implies some kind of hardware problem.
Angus
Without seeing the boot logs it's hard to tell exactly what happened. Normally on first boot the bootloader would not burn FLASH_CRYPT_CNT to 0x1 until after it encrypts the bootloader all partitions, so I can't provide an explanation for how this efuse was burned but the partitions were still plaintext. Is it possible the flash chip has enabled hardware write protection somehow? Or that the FLASH_CRYPT_CNT efuse had been burned already before flashing of the plaintext firmware was done?
If FLASH_CRYPT_CNT value is 0x2 then it should be possible to boot a plaintext bootloader. The "flash read err, 1000." indicates that the bootloader header at offset 0x1000 in the flash is invalid. Can you read the flash back and confirm that this part of the bootloader is not corrupted?
Agree with WiFive's suggestion that an intermittent failure on only some boards with the same provisioning process implies some kind of hardware problem.
Angus
-
- Posts: 6
- Joined: Wed Aug 19, 2020 4:02 pm
Re: Issue after enabling secure boot and flash encryption togeather [IDFGH-3857]
Hi Angus,
Error logs:
What are the possible hardware problems which may damage the board?
How we can enable Hardware write protection? From the menuconfig ? We have used the same binaries in all the 25 modules. Still, this can be the issue?Is it possible the flash chip has enabled hardware write protection somehow? Or that the FLASH_CRYPT_CNT efuse had been burned already before flashing of the plaintext firmware was done?
Sorry, I have written the wrong statement here. When I burn FLASH_CRYPT_CNT to disable flash encryption it's value was ox3, so flash encryption is disabled and then I have flashed the plain text binary. But then I am getting continuously "secure boot check fail" error. I am attaching Error logs and eFuse summary for the same.2. check eFuse summary and found FLASH_CRYPT_CNT 0x2
Error logs:
eFuse Summary:rst:0x10 (RTCWDT_RTC_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6456
load:0x40078000,len:15840
ho 0 tail 12 room 4
load:0x40080400,len:5844
secure boot check fail
ets_main.c 371
ets Jun 8 2016 00:22:57
espefuse.py v2.6
Connecting...
EFUSE_NAME Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 3 R/W (0x3)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 1 R/W (0x1)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 1 R/W (0x1)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 1 R/W (0x1)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 1 R/W (0x1)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 1 R/W (0x1)
BLK1 Flash encryption key
= ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLK2 Secure boot key
= ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLK3 Variable Block 3
= 01 02 03 00 02 00 03 03 00 00 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
Efuse fuses:
WR_DIS Efuse write disable mask = 384 R/W (0x180)
RD_DIS Efuse read disablemask = 3 R/W (0x3)
CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)
Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)
What are the possible hardware problems which may damage the board?
Who is online
Users browsing this forum: ESP_Sprite, ltsm0265 and 94 guests