espflash save-image does not support secure padding

[ivmarkov]

Enabling ESP Secure Boot V2 means the .bin image that results from converting an app image .elf with espflash save-image should be:

• Ideally having a sha256 "integrity" hash; this is done already
• Be padded (a.k.a. secure padding) - if necessary - with an extra segment of type PADDING in such a way, that the image file total length - including the single-byte checksum and including the sha256 "integrity" hash - ends up being divisible by 65536 (i.e. image should be aligned to the 64K boundary)

The ESP IDF Python tooling can do that e.g. as follows:

cargo install --git https://github.com/ivmarkov/esptools
esptools tool --chip esp32s3 elf2image --version 2 --secure-pad-v2 --output my-firmware-padded.bin target/xtensa-esp32s3-espidf/debug/my-firmware

Looking at the resulting binary image with e.g.

esptools tool --chip esp32s3 image_info my-firmware-padded.bin

... reveals something like:

Tool esptool mounted as `/home/ivan/.cache/esptools/78c195b08bd57bf27167b323600d417a546d3393/esptool`
Executing `esptool`
esptool.py v4.8.1
File size: 1966080 (bytes)
Image version: 1
Entry point: 40376ea8
8 segments

Segment 1: len 0x7d3a8 load 0x3c140020 file_offs 0x00000018 [DROM]
Segment 2: len 0x02c48 load 0x3fc99200 file_offs 0x0007d3c8 [BYTE_ACCESSIBLE,MEM_INTERNAL,DRAM]
Segment 3: len 0x139e48 load 0x42000020 file_offs 0x00080018 [IROM]
Segment 4: len 0x03528 load 0x3fc9be48 file_offs 0x001b9e68 [BYTE_ACCESSIBLE,MEM_INTERNAL,DRAM]
Segment 5: len 0x151a0 load 0x40374000 file_offs 0x001bd398 [MEM_INTERNAL,IRAM]
Segment 6: len 0x0005c load 0x600fe000 file_offs 0x001d2540 [RTC_DRAM,RTC_IRAM]
Segment 7: len 0x00008 load 0x600fe05c file_offs 0x001d25a4 [RTC_DRAM,RTC_IRAM]
Segment 8: len 0x0da14 load 0x00000000 file_offs 0x001d25b4 [PADDING] <- !! Look here !!
Checksum: 9b (valid)
Validation Hash: 4ffc9081ffa41085b109511b82c67af4ef69828154a64692ab4f5118f1f0aeaf (valid)
Status Ok(ExitStatus(unix_wait_status(0)))

... where the tool did create the [PADDING] section in such a way, so as the total image size (1966080) is divisible by 65536, as the ESP IDF Secure Boot V2 documentation requires.

In contrast, doing

espflash save-image --chip esp32s3 target/xtensa-esp32s3-espidf/debug/my-firmware my-firmware.bin

... results in something which is not really padded - and - moreover - contains the bootloader, partition table and factory image being concatenated (which is a separate issue - but still quite an issue - altogether for which I opened another report - #714).

[SergioGasquez]

Quick update, created main...SergioGasquez:espflash:feat/secure-padding, where padding is already added but does not show a padding segment:

• Generated with esptool shows:

Tool esptool mounted as `/home/sergio/.cache/esptools/78c195b08bd57bf27167b323600d417a546d3393/esptool`
Executing `esptool`
esptool.py v4.8.1
File size: 393216 (bytes)
Unexpected chip id in image. Expected 13 but value was 9. Is this image for a different chip model?
Image version: 1
Entry point: 40800a1a
6 segments

Segment 1: len 0x11a5c load 0x42040020 file_offs 0x00000018 [IROM]
Segment 2: len 0x0922c load 0x40800000 file_offs 0x00011a7c [DRAM,BYTE_ACCESSIBLE,IRAM]
Segment 3: len 0x01be4 load 0x40809230 file_offs 0x0001acb0 [DRAM,BYTE_ACCESSIBLE,IRAM]
Segment 4: len 0x03774 load 0x00000000 file_offs 0x0001c89c [PADDING]
Segment 5: len 0x3cb90 load 0x42000020 file_offs 0x00020018 [IROM]
Segment 6: len 0x03418 load 0x00000000 file_offs 0x0005cbb0 [PADDING]
Checksum: dd (valid)
Validation Hash: eb044cabeb6db222d6d444f9e9902a519983be9b73932d45e8b5c085ee793bab (valid)
Status Ok(ExitStatus(unix_wait_status(0)))

• Generated with espflash shows:

Tool esptool mounted as `/home/sergio/.cache/esptools/78c195b08bd57bf27167b323600d417a546d3393/esptool`
Executing `esptool`
esptool.py v4.8.1
File size: 393216 (bytes)
Image version: 1
Entry point: 40800a1a
5 segments

Segment 1: len 0x3cb90 load 0x42000020 file_offs 0x00000018 [IROM]
Segment 2: len 0x03460 load 0x40800000 file_offs 0x0003cbb0 [DRAM,BYTE_ACCESSIBLE,IRAM]
Segment 3: len 0x11a5c load 0x42040020 file_offs 0x00040018 [IROM]
Segment 4: len 0x05dcc load 0x40803460 file_offs 0x00051a7c [DRAM,BYTE_ACCESSIBLE,IRAM]
Segment 5: len 0x01be4 load 0x40809230 file_offs 0x00057850 [DRAM,BYTE_ACCESSIBLE,IRAM]
Checksum: dd (valid)
Validation Hash: 9ad6c27d67a45d3592707770beb0d22ef2fe09fb7e21b60651ab2b64c721fa11 (valid)
Status Ok(ExitStatus(unix_wait_status(0)))