Detect oversized app image about mcuboot

[ccollins476ad]

Newt is able to detect this condition via the MCU_FLASH_MIN_WRITE_SIZE setting. This setting indicates the MCU's minimum flash write size. Newt uses this setting to calculate the size of a hypothetical image trailer, and therefore the maximum allowed size of the image data.

[SebastianBoe]

If the image trailer was built into the image when the application was first linked/built one could detect this (linker error) by having a memory region that limited the space used.

(This approach solves other problems as well)

[mbolivar]

If the image trailer was built into the image when the application was first linked/built one could detect this (linker error) by having a memory region that limited the space used.

Interesting idea!

(This approach solves other problems as well)

But it causes additional ones: now all application binary images are as large as the slot itself (with padding bytes in between), which wastes bandwidth to FOTA, etc.

A linker-based approach, I think, should instead force the linker script to leave room for the trailer in the memory entry for ROM, but not actually include it.

What do you think?

[SebastianBoe]

A linker-based approach, I think, should instead force the linker script to leave room for the trailer in the memory entry for ROM, but not actually include it.

That is better than today's solution at least, so if not my proposal then yes indeed.

But it causes additional ones: now all application binary images are as large as the slot itself (with padding bytes in between), which wastes bandwidth to FOTA, etc.

? I don't think so, my claim is that it is possible to get the same hex as you do when you post-process with imgtool. I can prove this by example later, but it is interesting for me to hear now if there are any other problems with this approach.

EDIT: Something like

SECTION_PROLOGUE(image_pad, (NOLOAD OPTIONAL),)
{
. = ALIGN(_image_align);
} GROUP_DATA_LINK_IN(RAMABLE_REGION, RAMABLE_REGION)

SECTION_PROLOGUE(_IMAGE_TRAILER_SECTION_NAME, (OPTIONAL),SUBALIGN(4))
{
__image_trailer_start = .;
*(.image_trailer)
(".image_trailer.")
} GROUP_LINK_IN(RAMABLE_REGION, RAMABLE_REGION)

[mbolivar]

I don't think so, my claim is that it is possible to get the same hex as you do when you post-process with imgtool.

Operative word being "hex", right? When I said "binary images" I meant "bin"

[SebastianBoe]

Ah, right, but I assume one would never need to FOTA a binary image? I am not familiar with this domain.

EDIT: My personal experience with embedded in general is that bin is never used as a binary format (for obvious reasons).

[mbolivar]

We only ever FOTA binary images (over IP), actually -- the Zephyr applications don't have a .hex parser, so they just receive the signed blob and write it directly to slot 1, then reset.

[utzig]

This is very hard to do in the bootloader itself (impossible maybe?) because checking would have to be done before beginning a swap. The problem is that once a swap is under way, and the device is reset, the checking will possibly fail on next boot because one cannot determine the size of the image. It would be possible to read swap_size from the trailer maybe, but it's hard to know if it's correct.

For the swap-move implementation this was straight-forward because only sector indexes are required, since trailer and image data can never exist on the same sectors. But this mode is not supposed to work on devices that have weird layouts (eg STM32 with large non-linear sectors).

So part of fixing this is adding creation checks, like done in PR #636 for imgtool. A similar change needs to be added to newt. Another thing to check is if there is overlap of trailer in the scratch area with image data, in those cases where an image is big enough to require the trailer to be created on scratch (this would also be the case in some STM32 with large sectors).