main() loaded a file of any size and parsed it as a manifest: header
fields (size, TLVs) were read past the end of the heap allocation, and
a header claiming a larger fw_size drove the image hash over an
unbounded range. Reject files smaller than IMAGE_HEADER_SIZE before
parsing and clamp fw_size to the bytes actually loaded.
wolfBoot_start() in hal/library.c ended its exit: path with an
unconditional 'return 0;', so a rejected image (bad header, hash or
signature) still made the test-lib process exit 0. main() propagates
wolfBoot_start()'s return value, so the failure was only visible in
the printed "Failure" message, which the test-library workflow had to
grep for (TODO referencing PR #625).
Return ret, which carries the wolfBoot_verify_*() error on every path
that reaches exit: with a failure. The success path never returns:
do_boot() jumps to the firmware.
The test-library workflow drops the status-rewriting workaround and
asserts the non-zero exit code directly, keeping the "Failure"
message check as a diagnostic.
Verification:
- Built: make test-lib (host, library.config, ED25519/SHA256).
- Tested: local repro of the workflow flow: corrupt the last byte of
a signed image; before the fix the process exited 0 while printing
"Failure -1", after the fix it exits 255; a valid image still
exits 0 with "Firmware Valid".
- Pitfalls: 'return ret' only changes the error paths; do_boot() does
not return on success.
- Style: the cstyle-check.sh FMT flag on hal/library.c is present on
the pre-change file as well (not introduced here).
- Message: F-9749: prefix, no co-author trailers.
wolfGlass is public, so actions/checkout resolves the pinned revision with
the default token. Requiring WOLFGLASS_TOKEN made the job skip itself
whenever the secret was absent, which is every fork pull request, so the
one guard that holds tools/sbom/ to its pin was off for exactly the
contributors whose vendored copy nobody has reviewed.
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 cross_targets matrix lists config file names, and the step passed the
same string as TARGET. For four of the seven entries that is not the
target the config selects: nrf52840.config sets TARGET=nrf52,
imx-rt1060.config sets imx_rt, nxp-t1040.config sets nxp_t1040, and
renesas-rx65n.config sets rx65n.
TARGET on the command line beats the config, so the build asked for
hal/nrf52840.o, whose source does not exist. SBOM_SRCS filters the source
list through $(wildcard), which dropped it, and the job stayed green
while publishing an SBOM for a bootloader with no target HAL at all:
29 sources, hal.c present, nrf52.c absent.
Drop the TARGET override and let the config decide, which is what the
documented invocation already does. nrf52840 now records 30 sources with
hal/nrf52.c among them, and the document is named for the real target.
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>
Sync tools/sbom to wolfGlass 9bdf5b7: document --cflags -D-only
behavior, add WOLFSSL_DIR/version.h --dep-version fallback with correct
$$$$ expansion, and teach validate_sbom.py --min-properties. CI Make
path checks now require a non-empty property set so empty captures
cannot pass.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
The SBOM canary now guards the properties customers rely on, not only
that each route runs.
sbom_canary job adds three checks:
* Toolchain neutrality - build the same sim config with gcc and with
clang and require a byte-identical CycloneDX and SPDX result. The
driver captures configuration with the host compiler and a source
list, so the cross-toolchain that builds the firmware does not change
the SBOM. clang, LLVM and vendor compilers need no separate front end.
* Reproducibility - build the same config from a second absolute path
and require an identical SBOM, so no build path leaks into the output.
* Path scrub in a real build - build rp2350 with an absolute
PICO_SDK_PATH and assert the path is redacted while the macro key is
kept. This exercises the scrub through arch.mk, not a synthetic line.
New cross_targets job runs make sbom for a spread of architectures with
no IDE and no cross-toolchain installed: stm32h7, nrf52840, imx-rt1060
and sama5d3 (Arm), nxp-t1040 (PowerPC), renesas-rx65n (Renesas RX) and
hifive1 (RISC-V). The driver never calls the cross compiler, so each
target produces a valid SBOM on a plain runner. This proves the "any
target, any toolchain, no hardware" guarantee.
Every produced document is checked with validate_sbom.py and uploaded as
a build artifact.
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.
Under WOLFSSL_ARMASM, chacha.c calls wc_chacha_crypt_bytes(), which
arch.mk never adds for AArch64 -- it only pulls in the aes/sha ports.
Any AArch64 build using ChaCha failed to link. Add the object in
options.mk, where ChaCha is selected.
Also add a ChaCha variant of the zynqmp_sdcard ENCRYPT build to CI.
ForceZero() is only visible in libwolfboot.c, which pulls in misc.c
inline; update_disk.c called it without a declaration, so any config with
disk encryption failed to build. Use the exported wc_ForceZero() from
memory.o instead, which is always linked.
Add a zynqmp_sdcard ENCRYPT build job to CI, the only one that compiles
these paths.
Mattia Moffa
David Garske
Aidan Garske
Alex Lanzano
Daniele Lacamera
Marco Oliverio
Sameeh Jubran
Brett Nicholas
Mattia Moffa