Makefile no longer says a scan matches wolfssl:wolfcrypt. Re-vendor
wolfGlass at 48796ea so the generator contract exempts nested wolfcrypt.
Co-authored-by: Cursor <cursoragent@cursor.com>
The test-app Makefile was not linking nrf5340_uart.o (which defines
nrf5340_uart_crlf) for nrf5340% targets with DEBUG_UART=1, causing
'undefined reference to nrf5340_uart_crlf' when linking image.elf.
Also guard the main Makefile's nrf5340_uart.o with DEBUG_UART=1 for
consistency.
nrf5340: the target references nrf5340_uart_crlf (src/update_flash.c)
but the Makefile does not compile hal/nrf5340_uart.c, so the linker
fails. Add the object to OBJS (Makefile) and APP_OBJS (test-app).
cypsoc6: the new boot/update/swap vs bootloader-region #error guards
in include/target.h.in fire on the cypsoc6 layout, where the boot
partition intentionally overlaps the bootloader region (the bootloader
and the boot image share the same flash region). Introduce
WOLFBOOT_ALLOW_PART_OVERLAP (defined in cypsoc6.config, gated in
target.h.in, added to CONFIG_VARS in tools/config.mk) to suppress the
guards for targets that legitimately overlap.
Verified: nrf5340 builds (make distclean + cp config + make, exit 0,
wolfboot.bin created). cypsoc6 cannot be built locally (the CI checks
out lib/psoc6pdl from Infineon, which is not available locally), but
the WOLFBOOT_ALLOW_PART_OVERLAP guard is verified to suppress the
#error for the cypsoc6 layout.
Picks up per-configuration serialNumber and documentNamespace, so two
configurations of one wolfBoot version no longer share an identifier
inside a scanner. Also brings CPE/PURL build-metadata stripping,
--dep-* value validation, wolfcrypt version inheritance, and the
sbom.am host-cc macro capture.
The Makefile comment that recorded this as an open wolfGlass gap is
no longer true, so it goes.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
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>
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>
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 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>
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.
Four fixes needed by any wolfHSM client
- include/user_settings.h emitted "typedef struct WC_RNG WC_RNG;" whenever
WOLF_CRYPTO_CB && WC_NO_RNG, with no __ASSEMBLER__ guard, so a client built
with ARM thumb2 assembly failed to assemble wolfSSL's .S sources. Guard it.
- options.mk hardcoded WOLFHSM_CFG_COMM_DATA_LEN=5000 for every client. Make
it a variable (default unchanged) so ports whose transport slot is smaller
can override it.
- options.mk gated DEBUG_UART on the existence of the driver *object*, which
never exists on a clean tree, so DEBUG_UART was dropped on the very build
meant to enable it. Test for the source instead.
- Makefile unconditionally built an NVM key image with whnvmtool for
WOLFHSM_CLIENT=1. Add WOLFHSM_NVM_IMAGE=0 for ports that install the
verification key at boot instead.
The sbom target fed `cc -dM -E` an empty /dev/null with only
WOLFSSL_USER_SETTINGS, so gen-sbom's build properties collapsed to host
compiler builtins (all filtered out as noise) and the SBOM did not reflect
the selected configuration. Harvest the actual -D config macros from CFLAGS
(filtered in the shell so defines whose values contain spaces, e.g.
BOOTLOADER_PARTITION_SIZE=$((...)), survive intact) so the SBOM captures the
real TARGET/SIGN/HASH/feature set.
Also:
- add preflight checks for empty WOLFBOOT_VERSION and missing GEN_SBOM
- pass sources via --srcs-file to avoid ARG_MAX on large configs
- include .S sources in the source set, not just .c
- make HOSTCC and GEN_SBOM overridable
- README: soften "CRA Compliance" wording, use wolfboot-<version>.* names,
fix dangling wolfssl/doc/CRA.md link to point at the wolfSSL CRA Kit
Signed-off-by: Sameeh Jubran <sameeh.j@gmail.com>
Adds sbom target that produces CycloneDX and SPDX
SBOM files for a specific TARGET+SIGN combination.
Sources extracted from OBJS variable via wildcard.
wolfcrypt sources compiled into wolfBoot are listed
as wolfBoot's own sources (not a separate component).
Requires GEN_SBOM or WOLFBOOT_LIB_WOLFSSL set.
David Garske
Brett Nicholas
Aidan Garske
Sameeh Jubran
Alex Lanzano
Daniele Lacamera
Marco Oliverio
Mattia Moffa
Sameeh Jubran
Mark Atwood
aidan garske