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.
Run wolfBoot on the PIC32CZ CA9x host core (Cortex-M7) as a wolfHSM client,
offloading the image digest (SHA-256) and the ECDSA P-256 signature check to
the wolfHSM server.
The top-level Makefile defaults WOLFBOOT_ROOT to $(PWD), which is the
environment value of the invoking step: under the workflow's
working-directory (test-app/emu-test-apps) the keytools paths resolved
under the wrong root and keygen was never found, so src/keystore.c was
missing and the wolfboot build failed. Export the computed absolute
WOLFBOOT_ROOT so the make invocations resolve tool paths correctly
wherever the script is started from.
Add a GitHub Actions workflow covering the DUALBANK_SWAP fallback
scenario fixed by the previous commit, running on the m33mu emulator
(wolfboot-ci-m33mu image, which models the physical-bank BKER/SWAP_BANK
semantics of the STM32U5 flash controller).
The test drives three boots in a single emulator session with the
stm32u5-nonsecure-dualbank config:
1. wolfBoot verifies a valid v2 image in the UPDATE partition,
activates SWAP_BANK and reboots;
2. the v2 app, now running from physical bank 2, stages a fake v3
image with a broken integrity record into the logical UPDATE
partition and reboots;
3. wolfBoot selects the v3 update, fails verification, and must erase
the corrupt update and fall back to v2, which reports success via
breakpoint.
Besides the success breakpoint, the script checks the emulator flash
trace: the UPDATE partition must be erased and the BOOT partition
(holding the healthy image) must never be touched, so a regression
cannot hide behind an accidentally bootable state. Verified to fail
against the pre-fix hal_flash_erase, where boot 3 erases the healthy
image and the device bricks.
* file level rename for ML-DSA
* Add missing source file to build system
* Update some macros
* Other minor fixes
* Update size limitations for some slight increases
David Garske
Brett Nicholas
Daniele Lacamera
Aidan Garske
Mattia Moffa
Marco Oliverio
aidan garske
Alex Lanzano
Yosuke Shimizu
Tobias Frauenschläger
Thomas Cook