WOLFPSA_AES_FAST replaced with WOLFSSL_AES_TOUCH_LINES per the wolfPSA
5.9.4 constant-time policy; DICE.md and the MCXN verifier comment now say
ESP256 and state the RFC 9783 legacy-ID compatibility note.
The direct update->BOOT copy left the update partition at
IMG_STATE_UPDATING, so wolfBoot_start() re-entered wolfBoot_update(0)
on every boot: a wasted verification, and with ALLOW_DOWNGRADE a full
BOOT re-flash on every power-up. Reset the update state to NEW after
the update succeeds, as the swap path's final erase does; the write is
best effort, so in setups where the bootloader cannot write the update
partition the documented application requirement covers it. Add a
DISABLE_BACKUP unit variant with a state-consumption test.
The P1021 QE and T10xx QE/FMan microcode blobs are validated only for
structural integrity (header magic, version, size bounds) before they
are activated; no cryptographic authentication is applied. State that
in Targets.md for both targets, with the deployment-model reasoning:
the P1021 microcode region sits inside the update partition, and the
T10xx regions require local board flash write access, which also
allows replacing the wolfBoot image itself.
Same residual claim as F-8000 and F-9761 (T10xx QE and FMan paths);
the bounds fixes for all three are already in master (000c05c7,
91c020a2). Product decision: no microcode authentication feature.
src/keystore.c holds the public keys that authorise a firmware update. The
build generates it from the signing key, so a fresh checkout does not hold it,
and the missing-source guard read that absence as an absent submodule. Every
Make-path SBOM job failed on it.
Depend on it, so it exists before the guard runs, and name it in the source
list unconditionally: sbom.mk expands SBOM_SRCS through $(call) while reading
the makefile, so a file that appears later can never reach the document.
Without that second half the guard passed while the document was still one
source short, which is the silent under-report the guard exists to prevent.
Build the list with $(shell) rather than $(wildcard). GNU make 3.81 caches
directory contents, so it never sees a source generated during the same run.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Four exclusions were implicit, and a reader had no way to see them from
the document itself:
* the compiler runtime (libgcc, newlib) is linked into every image and
appears nowhere;
* of the six submodules only wolfSSL becomes a component, so a wolfTPM,
wolfHSM or wolfPKCS11 advisory cannot match, even though the captured
configuration records that the stack is compiled in;
* the document records the source set rather than each file, so SPDX
reports filesAnalyzed: false and the Merkle hash cannot be taken apart;
* WOLFCRYPT_ONLY is set for nearly every configuration, so a scanner
reports wolfSSL TLS advisories against an image with no TLS, and
wolfBoot ships no VEX statement to answer them with.
The first is inherent to a source-set SBOM. The other three are open
work, and the wolfGlass component table and a VEX target are where they
get closed.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Both output files were wolfboot-<version>.{cdx,spdx}.json, so every
configuration at a given version wrote to the same two paths. wolfBoot has
on the order of 100 target configurations and each is a different image
with a different source set, so building a second one overwrote the first
with no warning.
Put TARGET, SIGN and HASH in the name, on the Make and the CMake route
alike, so the two routes stay in step.
This does not fix the identity of the documents themselves. gen-sbom
derives both the CycloneDX serialNumber and the SPDX documentNamespace
from name and version only, so sim and stm32h7 at 2.9.0 still share
urn:uuid:6dc51759-ade2-5967-b392-2f23ed0eb4df, which a tool that keys on
serialNumber treats as one project. That is a wolfGlass change, and it
is not worked around here.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>