mirror of https://github.com/wolfSSL/wolfBoot.git
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>
|
||
|---|---|---|
| .. | ||
| png | ||
| API.md | ||
| CMake.md | ||
| DICE.md | ||
| HAL.md | ||
| Loader.md | ||
| MCXN947-DICE.md | ||
| PQ.md | ||
| README.md | ||
| Renesas.md | ||
| SBOM.md | ||
| STM32-TZ.md | ||
| Signing.md | ||
| TPM.md | ||
| Targets.md | ||
| Windows.md | ||
| ata_security.md | ||
| azure_keyvault.md | ||
| compile.md | ||
| encrypted_partitions.md | ||
| firmware_image.md | ||
| firmware_update.md | ||
| flash-OTP.md | ||
| flash_partitions.md | ||
| fwTPM.md | ||
| hooks.md | ||
| keystore.md | ||
| lib.md | ||
| measured_boot.md | ||
| remote_flash.md | ||
| wolfHAL.md | ||
| wolfHSM.md | ||
README.md
wolfBoot Docs and Platform-Specific Details
See also: wolfBoot Product Overview and wolfBoot Manual.
- API.md - Overview of wolfBoot public APIs and how to use them.
- ata_security.md - ATA security features (lock/unlock, passwords) and wolfBoot integration.
- azure_keyvault.md - Using Azure Key Vault for key management and signing with wolfBoot.
- CMake.md - CMake-based build setup, presets, toolchains, and tips for building wolfBoot.
- compile.md - How to build/compile wolfBoot (toolchains, options, typical steps).
- encrypted_partitions.md - Creating and managing encrypted firmware/data partitions.
- firmware_image.md - wolfBoot firmware image format, layout, and metadata.
- firmware_update.md - Update flow: slots, verification, rollback, and recovery.
- flash-OTP.md - Using One-Time Programmable (OTP) regions in flash for secure data.
- flash_partitions.md - Flash partitioning schemes and configuration guidance.
- HAL.md - Hardware Abstraction Layer notes and porting considerations.
- hooks.md - User-defined hooks for injecting custom logic into the wolfBoot boot process.
- keystore.md - Keystore design, key storage, and access strategies.
- lib.md - Using wolfBoot as a library and linking/integration guidance.
- Loader.md - Loader/secondary stage behavior and handoff to application.
- measured_boot.md - Measured boot concepts and recording measurements (e.g., PCRs).
- png/ - Folder of images/diagrams referenced by the documentation.
- PQ.md - Post-quantum algorithms and PQC support in wolfBoot.
- README.md - Overview and index of the documentation set.
- remote_flash.md - Working with external/remote flash (SPI/QSPI, mapping, access).
- Renesas.md - Notes and specifics for Renesas platforms/ports.
- Signing.md - Keys, signatures, and the image signing workflow.
- STM32-TZ.md - STM32 TrustZone (Armv8-M) setup and usage with wolfBoot.
- STM32.md - STM32 platform notes, options, and integration tips.
- Targets.md - Supported targets and platform-specific configuration.
- TPM.md - TPM integration, measured boot, and attestation flows.
- wolfHSM.md - Integrating wolfHSM with wolfBoot for secure key operations.