[LinuxJedi]

A flash erase or program that fails while the PKCS#11 keyvault (src/pkcs11_store.c) commits a record went unnoticed. The store ignored the return values of hal_flash_erase() and hal_flash_write(), wolfPKCS11's wolfPKCS11_Store_Close() returns void, and on STM32U5 the HAL returned 0 anyway. wolfPKCS11 therefore treated the record as stored and did not write it again (since wolfSSL/wolfPKCS11#257 it only rewrites everything after a store that failed).

pkcs11_store: erase and program failures in cache_commit_entry(), restore_backup() and check_vault() are counted. A store window records the count at wolfPKCS11_Store_Open(), and the new wolfPKCS11_Store_CloseCommit() returns BUFFER_E when it changed during the window. wolfPKCS11_Store_Remove() does the same. The sector cache is shared, so every window open during a failure reports it; a window that lost nothing only makes wolfPKCS11 write all records again. The commit sequence itself (backup sector, then destination) is unchanged. user_settings.h defines WOLFPKCS11_CUSTOM_STORE_CLOSE_COMMIT, which wolfSSL/wolfPKCS11#265 adds: a wolfPKCS11 with it closes written records through wolfPKCS11_Store_CloseCommit() and writes the token again after a failure. The pinned wolfPKCS11 ignores the define and keeps calling wolfPKCS11_Store_Close(), so this can merge before or after it.

stm32u5: hal_flash_write() and hal_flash_erase() now check OPERR, PROGERR, WRPERR, PGAERR, SIZERR and PGSERR after each quad-word and each page, clear PG or PER and the flags, and return -1. The status is read before EOP is cleared, since clearing EOP writes the error flags back and clears them too. Both return -1 for a negative length or a span not inside the flash, where hal_flash_write() used to return 0 (TrustZone) or not check at all, and hal_flash_erase() returned 0 for pages past the top. docs/HAL.md notes that hal_flash_erase() returns non-zero on failure and that the keyvault depends on both functions checking the error flags.

Testing:

• unit-stm32u5-write also extracts hal_flash_erase(). Its mock wait erases pages and can fail one operation with chosen flags. New tests cover each error flag for write and erase, flags that are not errors, and out-of-range spans. The error and range tests fail on the HAL without the checks.
• unit-pkcs11_store (and -stalecache): new tests cover a failed write or erase in a window's close, a failure seen by every open window but not by a later one, wolfPKCS11_Store_Remove(), and failures while formatting the vault or restoring the header from the backup sector. They fail on the store without the tracking. The mock flash gains a one-shot hal_flash_erase_fail.
• The whole unit suite, in wolfboot-ci-sim:v1.0, gives the same results on master and on this branch (223 pass; the same 7 tests fail on both for lack of tools or SDKs in that image).
• In wolfboot-ci-m33mu:v1.25, the stm32h5-tz PKCS11_TESTAPP=1 run passes and stm32u5-wolfcrypt-tz.config builds, with the pinned wolfPKCS11 and with Let custom stores report records that did not commit wolfPKCS11#265 (which then calls wolfPKCS11_Store_CloseCommit()).
• Not tested on hardware. On U5 with TrustZone, bank 1 is always programmed through the secure registers; any error flags the hardware raised there were ignored before and now fail the write. Worth a boot and update check on a board before merging.

ZD 21908