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>
SBOM_SRCS runs the object list through $(wildcard), so a source that is
not on disk disappears before the driver sees it. The driver's own
--skip-missing warning then has nothing left to report, which is why it
never fires on the Make path that every embedded user takes.
The result is a document that under-reports the image with no diagnostic
anywhere. A sim-tpm build without lib/wolfTPM checked out silently loses
all eight tpm2*.c sources, and validate_sbom.py accepts the result even
though the captured configuration still records WOLFBOOT_TPM=1.
Compare the two lists instead. An object that maps to neither a .c nor a
.S on disk means a submodule or a vendor SDK is absent, so stop and name
the objects on stderr. SBOM_ALLOW_MISSING=1 accepts the partial document
for the cases where the SDK genuinely cannot be present, and still lists
what is missing; imx_rt is one, because it compiles three MCUXpresso
drivers from outside the source tree.
Every other example config either passes or names only submodule paths
that CI checks out, so no job needs the escape hatch.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
tools/sbom/.wolfglass-rev named 1bfcf4f1a293ba09f0ff6d67904dca09ee8eb6d7,
which exists in no repository. The vendored content is wolfGlass
d34a906638444b6990218a49927bcebafc5a539b: tools/wolfglass-sync --check
against that revision reports every file identical and only the pin
itself as drift.
A bare SHA with nothing checking it is also how a 1803-line vendored
generator drifts from the copy wolfSSL controls, or carries a local
patch, without anything noticing. Add a job that checks wolfGlass out at
the pinned revision and runs its own tools/wolfglass-sync --check, which
compares every vendored file against share/ and the pin against HEAD. An
unresolvable revision now fails that job rather than sitting in the tree.
A fork PR has no token to read wolfGlass with, so the job reports a
notice and passes there; the run on wolfSSL/wolfBoot is the gate.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor wolfGlass tip where PRODUCT_CPE marks wolfboot registered
(NVD dictionary entries created 2026-08-10). Docs drop the "no CPE yet"
wording. The main package now carries cpe:2.3🅰️wolfssl:wolfboot:<ver>.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
The bootloader is built WOLFCRYPT_ONLY: include/user_settings.h defines
it for every configuration except a wolfHSM server with certificate-chain
verification, so the image carries the crypto subset of wolfSSL and no
TLS. The SBOM said nothing about that, leaving an integrator to triage
TLS advisories against a bootloader that cannot run TLS. The re-vendored
generator reads the macro out of the captured configuration and records
the subset; the wolfssl component stays, because it is the identifier NVD
maps wolfSSL advisories to and the wolfcrypt one has no CVEs mapped to it
at all. wolfcrypt is now nested inside wolfssl rather than beside it,
which is where it ships from.
wolfBoot also stopped emitting a CPE. NVD has no wolfssl:wolfboot entry,
and an unlisted CPE is indistinguishable to a scanner from a listed one
with no advisories; the submitted identifier is recorded as
wolfssl:sbom:cpe-requested until the dictionary request is published.
The CMake route passed its -D set with no settings header, so it recorded
none of the configuration user_settings.h derives from that set -- a
different document than `make sbom` produced from the same tree, and one
that could not see WOLFCRYPT_ONLY. It now passes the same SETTINGS_H and
INCLUDE_DIRS the Makefile does.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor the wolfGlass tip that gives every dependency component a CPE
alongside its PURL, and that emits pkg:github identifiers a consumer can
actually resolve. The wolfSSL entry in a wolfBoot SBOM previously carried
a PURL only, and that PURL pointed at a git tag which does not exist
(wolfSSL releases are tagged `-stable`), so an integrator monitoring NVD
could not match wolfSSL advisories against this firmware.
The CMake route also described a different product than the Make route:
it never declared the wolfSSL dependency, so its `components` array was
empty, and it recorded wolfBoot as a GPL-3.0-only library rather than a
GPL-3.0-or-later firmware image. Both routes now emit the same component
identity for the same configuration.
wolfCrypt stays inventoried as wolfBoot's own sources. It is not a
separate NVD product; its advisories are published against
wolfssl:wolfssl, so the wolfSSL identifiers cover that code.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Re-vendor wolfGlass a54cde1 and declare what the capture needs.
wolfBoot's wolfCrypt configuration is derived rather than literal:
include/user_settings.h turns WOLFBOOT_SIGN_ECC256 into HAVE_ECC,
HAVE_ECC256, ECC_TIMING_RESISTANT and the rest. Capturing CFLAGS alone
recorded the -D set and none of what it selects, so the SBOM described a
signing bootloader with no signature algorithm. Point SBOM_SETTINGS_H at
the wolfCrypt settings header, give it SBOM_INCLUDE_DIRS, and make
include/target.h a prerequisite since user_settings.h includes it and it
carries the flash layout.
For an stm32u5 ECC256 build the configuration record now holds 151
defines, including WOLFBOOT_SIGN_ECC256, HAVE_ECC, HAVE_ECC256,
WOLFBOOT_HASH_SHA256 and IMAGE_HEADER_SIZE=256, none of which appeared
before. BOOTLOADER_PARTITION_SIZE is 65536 rather than the literal `)`
that Make's double expansion had left in its place.
Declare wolfSSL as a dependency component by default, pinned to the
submodule's version. wolfCrypt is compiled into the image rather than
linked, so its sources are listed as wolfBoot's own; recording the
dependency as well is what lets a scanner match wolfSSL advisories
against this firmware.
Record the product as firmware rather than a library, in CycloneDX
component.type and SPDX primaryPackagePurpose alike. Override the
licence to GPL-3.0-or-later: LICENSE is the verbatim GPLv3 and says
nothing about how wolfBoot licenses under it, while all 252
GPL-headered sources say "either version 3 ... or (at your option) any
later version". The per-HAL SBOM inherits the override so the two
documents cannot contradict each other.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
wolfBoot ships as source. Users build it in many ways. Before this
change, only the plain Make build could make an SBOM. So a user could not
make an SBOM for the build that the user runs.
This change adds one shared engine (tools/scripts/wolfboot-sbom.sh, which
calls wolfSSL gen-sbom) and a front end for each build system. Every
build makes a CycloneDX 1.6 and SPDX 2.3 document. The engine captures
the configuration with the host compiler, so the SBOM is the same for
GCC, Clang, LLVM, IAR, armcl, CCRX, and XC32.
Routes:
- Make, arch.mk, and vendor SDKs: make sbom TARGET=<t> SIGN=<a>
- CMake and the Pico SDK: cmake --build <dir> --target sbom
- IAR Embedded Workbench: ide-sbom/iar_sbom.py
- Any IDE with a compilation database: ide-sbom/compdb_sbom.py
- TI CCS, MPLAB X, Renesas, Xilinx: ide-sbom/route_through_sbom.sh
- Per-HAL component: make sbom-hal TARGET=<t>
- Zephyr module: ide-sbom/zephyr_sbom.py
Make the SBOM reproducible. The captured macros can hold an absolute host
path. For example, arch.mk passes -DPICO_SDK_PATH=$(PICO_SDK_PATH). The
driver now redacts each absolute path but keeps the macro name, so the
configuration record stays complete. Add --no-scrub for debug.
Add a validator (ide-sbom/validate_sbom.py) and a CI canary
(.github/workflows/test-sbom.yml) that runs and validates every route.
The canary also checks that no host path leaks into the SBOM.
Add docs/SBOM.md. The tools are product-neutral by design, so they can be
shared across wolfSSL products later without logic changes.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
test-configs.yml already builds this config; what nothing covers is the
keytools half of the documented procedure -- signing and encrypting an
AArch64 payload and assembling the boot image. That is where the wrong
key size in the docs hid, so build it in CI.
Builds with DEBUG_UART=1, the mode the docs tell users to run and one
that did not compile until now. It stops short of booting: the target
emits nothing on the console under QEMU, so there is nothing to assert.
DEBUG_UART=1 did not compile: uart_init() declared an unused local and
-Werror rejected it, so the target's console output could never be
enabled. Drop the local.
The documented key file is 44 bytes, but AES256-CTR wants a 32-byte key
plus a 16-byte IV; sign fails with "Error reading IV" as written. Use
48 bytes, matching the key the HAL used to carry.
Drop the internal report numbers from source, test and Makefile
comments: they mean nothing outside the tracker and do not belong in
the tree. Condense the long inline comment blocks the review flagged,
and note in the raspi3 encrypted example and its docs that CI builds
but does not boot it, so the end-to-end path has no automated
coverage.
Comments and docs only; no functional change.
Removing the hardcoded test key is right, but nothing on this target
calls wolfBoot_set_encrypt_key() any more, so the shipped example and
the docs walk-through (whose example key was that same test key) no
longer boot an encrypted image. Say so in both places.
Aidan Garske
David Garske
Marco Oliverio
Brett Nicholas
Daniele Lacamera
Sameeh Jubran