Skip to content

Last sector of the firmware in boot partition gets corrupted in wolfBoot_swap_and_final_erase #589

Closed

Description

@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.

Activity

  1. dgarske commented on Sep 5, 2025

    @dgarske
    Member

    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

  2. reza-hdd commented on Sep 5, 2025

    @reza-hdd
    Author

    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

  3. danielinux commented on Sep 9, 2025

    @danielinux
    Member

    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

  4. reza-hdd commented on Sep 10, 2025

    @reza-hdd
    Author

    Hi Daniele,
    Thank you for looking at that.

    Regards,
    Reza

  5. danielinux commented on Sep 10, 2025

    @danielinux
    Member

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

    Thanks again for reporting this!

  6. reza-hdd commented on Sep 10, 2025

    @reza-hdd
    Author

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

  7. reza-hdd commented on Sep 12, 2025

    @reza-hdd
    Author

    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?

  8. danielinux commented on Sep 12, 2025

    @danielinux
    Member

    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.

  9. danielinux commented on Sep 13, 2025

    @danielinux
    Member

    fixed in #592, merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions