wolfBoot now runs on the NXP i.MX 8QuadMax MEK as BL33, taking the place of U-Boot inside the NXP boot container. The i.MX 8QuadMax is used in automotive, industrial and medical designs, where the boot chain often has to be auditable, and this puts a small bootloader that checks a signature in the last position before the operating system starts. It verifies a signed Linux image and boots it, using the same wolfCrypt code already deployed elsewhere in those systems, so the final stage before the OS is one you control and one that refuses to run an image it cannot verify.
What it does
- Runs as the bare-metal BL33 stage. The System Controller firmware trains DDR before any application core starts, so wolfBoot has no memory init to do and hands off from EL2 to EL1.
- Verifies a signed Flattened uImage Tree (FIT) read from either the SD card or the on-board eMMC, selecting the A or B boot slot by GPT partition label.
- Falls back to the second slot when the first fails verification, and refuses to fall back to an older version, so a failed update cannot become a downgrade.
- Brings up the peripherals it needs through the System Controller Unit (SCU), including power, clocks, pad routing and clock gating.
- Supplies the runtime device tree fixups the operating system expects, covering the kernel command line and the real memory map.
- Signs and packages the boot container for NXP AHAB.
Hardware validated
Booted end to end on an i.MX 8QuadMax MEK, from a container built from source through to a Linux 6.1.22 login prompt on an ext4 root filesystem, from both the SD card and the eMMC. A/B slot selection and failover were both confirmed on the board, as was reading, erasing and programming the FlexSPI NOR flash.
Verification is close to free. Measured while booting a 32 MB signed FIT:
| Stage | Time |
|---|---|
| Reading the image from the SD card | 1554 ms |
| SHA-384 hash of the image | 4011 ms |
| ECDSA P-384 signature check | 7 ms |
The signature check is 7 milliseconds. Adding verified boot to this design costs essentially nothing in boot time.
Root of trust
The chain is anchored in hardware. The SoC’s AHAB secure boot has its SECO firmware authenticate the boot container, which holds the System Controller firmware, ARM Trusted Firmware, and wolfBoot itself, against a Super Root Key hash burned into fuses, before any application core runs. wolfBoot then verifies the operating system image. AHAB protects wolfBoot, and wolfBoot protects what it boots. The chain is complete once the Super Root Key hash is fused and the part is closed, which is a production step, and the development board used here is an open part.
Standards and certification
- CNSA 2.0: wolfBoot supports the post-quantum signature algorithms the NSA’s CNSA 2.0 suite calls for, including LMS, XMSS and ML-DSA, so a design that has to migrate off ECDSA can do so by changing the signing algorithm rather than the bootloader.
- FIPS 140-3: wolfBoot can perform its verification with the wolfCrypt FIPS 140-3 module, which runs its power-on self test and integrity check before the boot is allowed to proceed.
- DO-178C DAL-A: wolfCrypt DO-178C DAL-A certification artifacts are available for avionics programs. wolfSSL has completed certifications on other platforms, including Intel Tiger Lake, and can certify additional platforms on request.
Full details are in the PR 887.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now