We're doing some oddities in our linker script that differ from what is
done by default. To that end, we'd like to provide our own linker script
so we don't have to carry patches forward
- Add NVM ECC mode, which introduces a new erase check HAL API to use
flash controller HW to blank check sectors instead of reading them
and comparing to an erased byte (which typically triggers an ECC
fault)
- Add NVM Journal mode as an alternative to NVM_FLASH_WRITE_ONCE that
does not require a sector-size RAM buffer and dramatically reduces
the number of erases and programs required to set individual flags,
while also being much more robust to power-cuts.
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>