boot: bootutil: Fix swap-scratch when the trailer is larger than the last sector

[taltenbach]

When swap-scratch is used and the trailer is larger than the last sector of the primary and/or the secondary slot, the upgrade would fail and a potential flash memory corruption could occur due to an underflow in case a sector contains both part of the firmware image and part of the trailer.

This issue was not shown by the simulator since when max-align-32 is not selected, the trailer fit in a single sector in all tested configuration, and when max-align-32 is selected, the firmware image size is chosen so that no sector contain both part of the firmware image and part of the trailer. So, perhaps that's a known limitation and it is expected the users ensure their firmware images are small enough so that this issue doesn't occur, but since I didn't find any documentation mentioning that point and that using a too large image could lead to potentially dangerous underflow, I've considered that as being a bug and attempted to fix it.

The first commit modifies the simulator to compute the maximum firmware image size the same way, irrespective of whether or not max-align-32 is selected, allowing in both case the sector containing the first part of the trailer (or the whole trailer if it is small enough) to also contain part of the firmware image. As expected, this leads to the tests to fail in the configuration where the trailer doesn't fit in a single sector.

The following commits fixes the issue in the swap-scratch implementation.

---

Example of configuration where the issue occurs:

• Primary slot: 680 KiB -> 170 * 4096-byte sectors
• Secondary slot: 680 KiB -> 85 * 8192-byte sectors
• Scratch area: 8 KiB -> 1 * 8192-byte sector
• Flash write size: 32 bytes

Therefore:

• Slot trailer size: (3 * 85 * 32) + (32 * 5) = 8320 bytes
• Scratch trailer size: (3 * 1 * 32) + (32 * 5) = 256 bytes

This leads to:

         PRIMARY                               SECONDARY                              SCRATCH
|          ...          |              |          ...          |
+-----------------------+              +-----------------------+             +-----------------------+
| Firmware (4096 bytes) | Sector 166   | Firmware (8064 bytes) | Sector 83   | Firmware (7936 bytes) |
|           .           |              |           .           |             |           .           |
+-----------------------+              |           .           |             |           .           |
| Firmware (3968 bytes) | Sector 167   |           .           |             |  Trailer (256 bytes)  |
|  Trailer (128 bytes)  |              | Trailer  (128 bytes)  |             |           .           |
+-----------------------+              +-----------------------+             +-----------------------+
|  Trailer (4096 bytes) | Sector 168   | Trailer  (8192 bytes) | Sector 84
|           .           |              |           .           |
+-----------------------+              |           .           |
|  Trailer (4096 bytes) | Sector 169   |           .           |
|           .           |              |           .           |
+-----------------------+              +-----------------------+

The first operation performed by the swap-scratch algorithm is to swap the last sector containing part of the firmware image. Assuming the image is larger than 672 KiB, this means swapping sectors 166+167 (primary) and 83 (secondary) in this example. This operation is performed by the boot_swap_sectors routine with sz == 8192. Before the fixes introduced by this MR:

• copy_sz was computed as sz - trailer_sz = 8192 - 8320 = -128, so copy_sz == 4294967167 after wrap around.
• copy_sz was computed without taking the size of the scratch area into account. In this example, it is clear that if the whole 8064 bytes of firmware data are copied from sector 83 (secondary) to the scratch area, the trailer of the scratch area would be overwritten. copy_sz must therefore be adjusted to ensure the scratch trailer won't be corrupted.
• Only sectors 166+167 (primary) and 83 (secondary) were erased, causing in particular issues when attempting to rewrite the trailer in the primary slot.

[d3zd3z]

Thanks for putting the work into figuring this out. I'm curious if this is enough to fix swap-scratch or swap-offset for things like the STM32F4, with just 3 128k sectors available.

[taltenbach]

Thanks for putting the work into figuring this out. I'm curious if this is enough to fix swap-scratch or swap-offset for things like the STM32F4, with just 3 128k sectors available.

@d3zd3z You're welcome :) Are you referring to #2052? I'm might be able to put some time into this issue in the following weeks.