tfm.c never tests WC_NO_HARDEN, so dropping it enabled nothing; it only
un-silenced the advisory #warning in settings.h, which -Werror turns
into a build failure for any USE_FAST_MATH + WOLFCRYPT_TZ_PSA build.
Define TFM_TIMING_RESISTANT, which is what makes tfm.c constant time.
The comment justified WC_NO_HARDEN on the grounds that 'wolfBoot only
does public asymmetric operations'. That is not true for software
DICE: with WOLFCRYPT_TZ_PSA and no WOLFBOOT_DICE_HW, src/dice/dice.c
retrieves the private IAK (wolfboot_attest_get_private_key) and signs
the attestation claims with wc_CoseSign1_Sign_ex(), and arch.mk still
selects USE_FAST_MATH for those builds. A configuration maintainer
trusting the comment would have left the private-key signing path
without timing hardening.
Gate the definition to verify-only configurations: WC_NO_HARDEN is
now defined only when WOLFCRYPT_TZ_PSA is absent or WOLFBOOT_DICE_HW
is set (hardware DICE keeps signing in the crypto engine), and the
comment states the actual rationale.
Verified with a preprocessor probe: plain fast-math and hardware DICE
still get WC_NO_HARDEN; software DICE no longer does.
The comment labeled IMG_STATE_TESTING as an 'ELF loading state', but
the constant is wolfBoot's general dual-bank confirm/rollback marker:
it is set on the BOOT partition after every swap (update_flash.c,
update_flash_hwswap.c, update_ram.c - none ELF-specific) and cleared
by wolfBoot_success(); if still present at the next boot it triggers
a rollback. A maintainer trusting the old comment could have treated
the state as inert on non-ELF targets and disabled the anti-brick
path.
Reword to the accurate description already used in
docs/flash_partitions.md, keeping the note that it only lives on the
boot partition so it cannot conflict with IMAGE_STATE_UPDATING.
Comment-only change; no code or behavior changes.
- wolfBoot_fit_memcpy: return int so a failed PDMA copy propagates instead
of being swallowed. The weak default (memcpy) returns 0; the MPFS250 PDMA
override returns -1 if any chunk's mpfs_pdma_memcpy() fails. Callers now
fail closed: fit_load_image_inner returns NULL (kernel load then panics
via update_disk.c), the update_disk DTS copy panics, and hal_dts_fixup
returns an error on a failed L2->DDR copy-back.
- options.mk: gate -DSTACK_SIZE_PER_HART behind RISC-V arch (RISCV/RISCV64).
The macro is only consumed by the RISC-V startup asm and the mpfs250-m.ld
sed token, so it is no longer emitted for PPC/ARM/other targets. The
unconditional default (?= 0) is kept because the linker sed always needs
a value to substitute.
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.
- Check diag_erase() return value in wolfBoot_record_failure()
- Dedicated WOLFBOOT_FAILURE_PHASE_SELF_UPDATE
- Mark the diagnostics flash write buffers XALIGNED_STACK(4) for HALs
that access the source word by word
- Ensure diagnostics, update, or swap partitions don't overlap the
bootloader
When boot/update partition verification fails during boot or update,
with this option the event is logged to flash in an ad-hoc partition.
Information about logged failures is made available to the application
through an API.
Allow to either use a master different that the sample one or to
directly use the pre-computed per-device auth values for EH and AIK.
Using the per-device value is preferred as it doesn't expose the auth
value of the sibling devices in the same fleet.
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.
security_command_passphrase used strlen(passphrase) on a 32-byte binary
buffer from TPM unsealing that carries no null-terminator guarantee,
causing an OOB stack read whenever none of the 32 key bytes is zero.
Replace strlen with strnlen(passphrase, ATA_SECURITY_PASSWORD_LEN) using
a new constant (32, matching the ATA-8 ACS password field size) defined
in ata.h. Also add a size check in sata_unlock_disk after
sata_get_unlock_secret so a short or malformed unseal result is rejected
before reaching the ATA command path.
Three related defects:
- panic() halted with a single hlt instruction (no loop), so any
resumable interrupt (LAPIC timer via iretq) caused it to return,
allowing callers to continue executing. Add while(1) and declare
__attribute__((noreturn)) in both definition and header.
- x86_paging_setup_ptp guarded with == WOLFBOOT_PTP_NUM instead of >=,
so if the counter ever exceeded that value (after a panic() return)
the guard was permanently bypassed.
- The ptp pointer was computed before the bounds check, creating an
out-of-bounds pointer for one-past-end indices; move the assignment
to after the guard so no invalid pointer is ever formed.
Add unit-x86-paging-oob test that sets page_table_page_used to
WOLFBOOT_PTP_NUM and verifies that every subsequent call to
x86_paging_setup_ptp triggers panic (via longjmp stub) rather than
silently proceeding with an out-of-bounds memset.
disk_open() computed bytes_left = n_part * array_sz from the GPT header and
scanned the whole declared partition-entry array (one disk_read per 512-byte
chunk) to compute its CRC32 *before* comparing against ptable.part_crc. Both
n_part and array_sz are taken verbatim from the GPT header, whose only gate is
a header CRC32 the attacker can freely recompute. A crafted header with e.g.
n_part=0xFFFFFFFF forces ~10^9 disk reads before the mismatch is detected: a
pre-auth denial of service that can trip a watchdog and block boot.
Reject the header when n_part * array_sz exceeds GPT_MAX_PART_ENTRIES (128, the
UEFI default) * GPT_PART_ENTRY_SIZE before entering the scan loop. The bound is
generous enough for any standard table (128 * 128 = 16 KiB) and for the
existing oversized-array test cases, but caps the scan at 64 sectors.
Add a regression test that crafts a header with a valid header CRC and an 8 MB
declared array and asserts disk_open performs no partition-array reads.