c3f9717f guarded the success/trigger/sector-flag declarations behind
WOLFBOOT_FIXED_PARTITIONS, but wolfboot.h includes target.h only under
__WOLFBOOT, so test-apps (compiled without __WOLFBOOT) never saw the
macro and failed with implicit-declaration errors on imx95_m7, mcxa,
mcxw and mcxw-tz. Unguard the header declarations; keep the definitions
guarded and move wolfBoot_success out of the fixed-partition guard
since it only uses the partition-state API.
- libwolfboot.c: keep the partition state APIs (set/get_partition_state)
available to CUSTOM_PARTITION_TRAILER / WOLFBOOT_NO_PARTITIONS builds;
guard the fixed-partition APIs (sector flags, erase, trigger, success)
behind WOLFBOOT_FIXED_PARTITIONS. Add the unit-custom-trailer-nopart
compile target to lock in that configuration.
- unit-p1021-fcm-bytes.c: add program tests for status 0x81 (fail) and
0x00 (write-protected), asserting no later page is programmed.
- unit-p1021-erase-advance.c: add an erase test for status 0x00
(write-protected), asserting failure before advancing to the next block.
Add HAVE_PARTITION_TRAILERS macro (set when WOLFBOOT_FIXED_PARTITIONS or
CUSTOM_PARTITION_TRAILER is defined) and use it to gate the TESTING state
transition in update_ram.c. Previously the gate was WOLFBOOT_FIXED_PARTITIONS
only, so targets using custom partition trailers never transitioned from
UPDATING to TESTING, allowing rollback to older versions.
Add unit-update-ram-custom-trailer test covering the CUSTOM_PARTITION_TRAILER
path with mocked get/set_trailer_at callbacks.
Every wolfPKCS11 field write flushed the payload sector and the header
sector to flash (2 erases + 2 programs of a full sector each), and the
token store re-serializes all objects per C_CreateObject/C_DestroyObject,
so those calls cost hundreds of sector erases and tens of seconds on
flash with slow erase times.
Cache modified sectors in RAM and commit them together when the store
window closes:
- sector cache sized to the worst-case span of one object plus the
header sector (WOLFBOOT_PKCS11_STORE_CACHE_SECTORS), LRU eviction
when exceeded
- header sector commits last, so a committed header is the atomic
commit point of the batch: power failure during a flush leaves the
flash in either the pre-batch or the post-batch state
- per-commit backup sector write preserved, keeping recovery of the
sector in flight at failure time
- delete_object commits on return (durability contract, unit-tested)
- nodes table, bitmap, payload ids and the live object size
(handle->size) are read from the cache when the sector is dirty
Measured on an STM32H5 with 8KB sectors, wolfPKCS11 in the secure
world: C_CreateObject 1.5s -> 0.15s, C_DestroyObject 1.3s -> 0.12s,
456 -> 40 sector erases per create, and the count no longer scales
with the number of objects in the token.
PKCS11_STORE_STATS (off by default) adds flash-activity counters and a
test-app bench to quantify store traffic: make PKCS11_STORE_STATS=1.
The comment labeled IMG_STATE_TESTING as an 'ELF loading state', but
the constant is wolfBoot's general dual-bank confirm/rollback marker:
it is set on the BOOT partition after every swap (update_flash.c,
update_flash_hwswap.c, update_ram.c - none ELF-specific) and cleared
by wolfBoot_success(); if still present at the next boot it triggers
a rollback. A maintainer trusting the old comment could have treated
the state as inert on non-ELF targets and disabled the anti-brick
path.
Reword to the accurate description already used in
docs/flash_partitions.md, keeping the note that it only lives on the
boot partition so it cannot conflict with IMAGE_STATE_UPDATING.
Comment-only change; no code or behavior changes.
- Check diag_erase() return value in wolfBoot_record_failure()
- Dedicated WOLFBOOT_FAILURE_PHASE_SELF_UPDATE
- Mark the diagnostics flash write buffers XALIGNED_STACK(4) for HALs
that access the source word by word
- Ensure diagnostics, update, or swap partitions don't overlap the
bootloader
When boot/update partition verification fails during boot or update,
with this option the event is logged to flash in an ad-hoc partition.
Information about logged failures is made available to the application
through an API.
* Initial port refresh for the NXP T2080 target
* IFC Flash driver and multi-core support on T2080
* Working wolfBoot test-app startup on T2080
* Support for NAII and Curtiss-Wright T2080 vendor boards
- Integrates wolfPSA as psa_crypto/psa_store engine in TrustZone
- Provides interface to access APIs from non-secure mode
- Patches to enable wolfboot as TEE module in zephyr
- Patches to enable stm32h563-nucleo/ns as target in zephyr
- psa_crypto zephyr example using wolfboot/wolfPSA as secure engine
Cleanup STM32H5 HAL port.
Refactor `__ARM_FEATURE_CMSE` to `TZ_SECURE()`
Refactor attribute cmse_nonsecure_entry to use new macro `CSME_NSE_API`
Added TPM Non Secure Callable API's
Added TPM support to STM32H5 test application
- Make the update and swap partitions secure and inaccessible from the
app except via NSC API
- Add a couple of necessary new NSC functions
- Update the app to only use NSC API
- Fix hal_flash_erase to account for secure addresses
- Fix some bugs in xmodem implementation
During fallback operations, use a different encryption IV than the one
used to encrypt the backup during the update. This ensures that the same
IV is never reused to encrypt different sectors.
As reported by @reza-hdd in #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.
This was due to the function wolfBoot_copy_sector() assuming that all
copies having an external SWAP as destination would not need any
encryption, as the "normal" case during update is to copy already
encrypted sectors from UPDATE->SWAP.
In the final state, after the update is successfully applied, the
mechanism saves a copy of the last sector from BOOT->SWAP. In this case,
if the application is big enough, an extra function is needed to
encrypt the content of this last sector before writing it to SWAP.
Restoring the backup is OK (normal case SWAP->BOOT, decryption was
already there as also noted by the reporter).
Daniele Lacamera
David Garske
Brett Nicholas
Mattia Moffa
aidan garske
Yosuke Shimizu
Thomas Cook
gojimmypi