You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Last sector of the firmware in boot partition gets corrupted in wolfBoot_swap_and_final_erase #589
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.
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.
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 :
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)
3- Content is restored from the Swap partition after final swap operation finished (Following wolfBoot_copy_sector shows content is decrypted when restored)
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?
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.
Activity
dgarske commentedon Sep 5, 2025
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.Thanks,
David Garske, wolfSSL
reza-hdd commentedon Sep 5, 2025
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=1the 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
2- Content of the sector copied to external Swap partition in line 296. (Following the
wolfBoot_copy_sectorshows content is not encrypted when copied to Swap)wolfBoot/src/update_flash.c
Lines 293 to 296 in 3801b49
3- Content is restored from the Swap partition after final swap operation finished (Following
wolfBoot_copy_sectorshows content is decrypted when restored)wolfBoot/src/update_flash.c
Lines 322 to 325 in 3801b49
The restored content is garbage as it was not encrypted when backed up but decrypted when restored.
Thanks,
Reza
danielinux commentedon Sep 9, 2025
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 commentedon Sep 10, 2025
Hi Daniele,
Thank you for looking at that.
Regards,
Reza
Fix corruption of last boot sector with encryption
danielinux commentedon Sep 10, 2025
Hello,
A fix is available in PR #592 - please let us know if this solves the issue.
Thanks again for reporting this!
reza-hdd commentedon Sep 10, 2025
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 commentedon Sep 12, 2025
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 commentedon Sep 12, 2025
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 commentedon Sep 13, 2025
fixed in #592, merged.