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.
Add a GitHub Actions workflow covering the DUALBANK_SWAP fallback
scenario fixed by the previous commit, running on the m33mu emulator
(wolfboot-ci-m33mu image, which models the physical-bank BKER/SWAP_BANK
semantics of the STM32U5 flash controller).
The test drives three boots in a single emulator session with the
stm32u5-nonsecure-dualbank config:
1. wolfBoot verifies a valid v2 image in the UPDATE partition,
activates SWAP_BANK and reboots;
2. the v2 app, now running from physical bank 2, stages a fake v3
image with a broken integrity record into the logical UPDATE
partition and reboots;
3. wolfBoot selects the v3 update, fails verification, and must erase
the corrupt update and fall back to v2, which reports success via
breakpoint.
Besides the success breakpoint, the script checks the emulator flash
trace: the UPDATE partition must be erased and the BOOT partition
(holding the healthy image) must never be touched, so a regression
cannot hide behind an accidentally bootable state. Verified to fail
against the pre-fix hal_flash_erase, where boot 3 erases the healthy
image and the device bricks.
Add wolfBoot support for booting VxWorks 7 SMP 64-bit (and signed ELF
images) on the NXP T2080 (e6500) / Curtiss-Wright VPX3-152.
Key fix: bring up the e6500 cluster L2 cache in the correct order -- set
L2PE (ECC) in its own polled write BEFORE enabling L2E, with L2FI|L2LFC --
matching CW U-Boot (SDK2.0). The previous bare-L2E init left the L2 ECC
array uninitialized for the kernel's 0x1E0000 set, machine-checking VxWorks
(MCSR[IF], L2ERRDET MBECC).
Also: ePAPR spin-table SMP bring-up of all four cores, ELF in-place loader
staging-overlap fix, DPAA/LIODN + QMan/BMan init, 64-bit OS handoff
(LAW/TLB/IVOR), and NAII 68PPC2 + CW VPX3-152 board configs.
David Garske
Sameeh Jubran
Brett Nicholas
Daniele Lacamera
Aidan Garske
Mattia Moffa
Alex Lanzano
aidan garske
Marco Oliverio
Yosuke Shimizu