Last sector of the firmware in boot partition gets corrupted in `wolfBoot_swap_and_final_erase`

[reza-hdd]

Scenario:
Boot partition: INTERNAL
Update partition: EXTERNAL
Swap Partition: EXTERNAL

When Firmware is large enough to consume all the allocated boot partition sectors, in the the final swap and erase operations (wolfBoot_swap_and_final_erase) the last sector of FW in Boot partition, which is used as a temporary sector for a copy operation, gets corrupted after being copied in external Swap partition and copied back. It looks like the contents are copied to the external Swap partition without being encrypted, but get decrypted when it is read back.

[dgarske]

Hi @reza-hdd ,

Thank you for the report. We will investigate. Can you tell us the hardware platform and share your .config?

We use the last sector for storing state. Are you using NVM_FLASH_WRITEONCE=1? If your onboard flash does not support erase and multiple writes then we must use 2 sectors.

Also if you have another place you'd like to store state you can override the functions using CFLAGS_EXTRA+="-DCUSTOM_PARTITION_TRAILER" and supply your own implementation for the trailer state. We do have some examples for this to share if you are interested.

/* Custom partition trailer
 * Function implementation externally defined
 */
uint8_t* RAMFUNCTION get_trailer_at(uint8_t part, uint32_t at);
void     RAMFUNCTION set_trailer_at(uint8_t part, uint32_t at, uint8_t val);
void     RAMFUNCTION set_partition_magic(uint8_t part);

Thanks,
David Garske, wolfSSL

[reza-hdd]

Hi David,

Thanks for following up. We are using STM32U5 and yes we are using NVM_FLASH_WRITEONCE=1 . Also as mentioned we use External encryption for Swap and Update partitions.
I know with NVM_FLASH_WRITEONCE=1 the last 2 sectors are used for partition status and I was not talking about those two sectors.
The problem is the 3rd last sector which is allowed for firmware to use it based on the size checks in Wolfboot and it is actually the last usable sector by the FW, but this is what happens to this sector when wolfBoot_swap_and_final_erase(0) is executed :

1- Pointer to last 3rd sector defined:

wolfBoot/src/update_flash.c

Lines 254 to 255 in 3801b49

	uintptr_t tmpBootPos = WOLFBOOT_PARTITION_SIZE - eraseLen -
	WOLFBOOT_SECTOR_SIZE;

2- Content of the sector copied to external Swap partition in line 296. (Following the wolfBoot_copy_sector shows content is not encrypted when copied to Swap)

wolfBoot/src/update_flash.c

Lines 293 to 296 in 3801b49

	if (updateState != IMG_STATE_FINAL_FLAGS) {
	/* First, backup the staging sector (sector at tmpBootPos) into swap partition */
	/* This sector will be modified with the magic trailer, so we need to preserve it */
	wolfBoot_copy_sector(boot, swap, tmpBootPos / WOLFBOOT_SECTOR_SIZE);

3- Content is restored from the Swap partition after final swap operation finished (Following wolfBoot_copy_sector shows content is decrypted when restored)

wolfBoot/src/update_flash.c

Lines 322 to 325 in 3801b49

	/* Restore the original contents of the staging sector (with the magic trailer if encrypted) */
	if (tmpBootPos < boot->fw_size + IMAGE_HEADER_SIZE) {
	wolfBoot_copy_sector(swap, boot, tmpBootPos / WOLFBOOT_SECTOR_SIZE);
	}

The restored content is garbage as it was not encrypted when backed up but decrypted when restored.

Thanks,
Reza

[danielinux]

Hello Reza,
Thanks for your patience. I've managed to reproduce in our simulator, and I'm working on a fix. I will keep you posted.

Kind Regards,

--
Daniele

[reza-hdd]

Hi Daniele,
Thank you for looking at that.

Regards,
Reza

[danielinux]

Hello,
A fix is available in PR #592 - please let us know if this solves the issue.

Thanks again for reporting this!

[reza-hdd]

Thanks Daniele for the quick fix. I'll test as soon as I can and will let you know the result.
Regards,
Reza

[reza-hdd]

Hi Daniele,
I pulled this fix and added to our bootloader which is v2.5 and it worked fine.
I see your fix is on top of v2.6 but since we need to apply this fix to our bootloader, just confirming if you foresee any issues with that if we use it with v2.5?

[danielinux]

Good question. I don't see anything in the changelog between 2.5.0 and 2.6.0 although some fuzzing may occurr when you apply the patch.
However we always recommend to update to the most recent version, if possible.

Thanks for confirming the fix! We'll proceed to merge the pull request after the reviews.

[danielinux]

fixed in #592, merged.