wolfBoot Brings Verified Boot to AArch64 UEFI: Booting Linux on the NVIDIA Jetson Orin Nano

wolfBoot now runs as a native AArch64 UEFI application, extending its measured, cryptographically verified boot to any 64-bit ARM platform that boots through UEFI firmware, and anchoring a complete ARM Root of Trust (RoT) from silicon to the operating system. We validated it end to end on an NVIDIA Jetson Orin Nano Developer Kit, taking it from power-on all the way to an Ubuntu 22.04 login prompt, with wolfBoot verifying the Linux kernel’s signature before it was ever allowed to run.

We then took it the rest of the way: the firmware now verifies wolfBoot through UEFI Secure Boot, and wolfBoot measures the kernel into the Jetson’s on-chip TPM, so every link from silicon to Linux is both verified and attestable. Here is how it fits together.

Why a UEFI application?

Many modern ARM platforms (including NVIDIA’s Jetson line) ship a vendor-signed early boot chain (BootROM, MB1, MB2, and an edk2-based UEFI firmware). As a first step, wolfBoot slots in right after that chain, as a standard wolfboot.efi PE/COFF application that the platform firmware loads like any other UEFI boot payload. A full vendor-firmware replacement, with tight integration to the hardware RoT, is on the wolfBoot roadmap.

From there wolfBoot reads the next-stage image, verifies its signature with wolfCrypt, applies A/B fallback logic, and only then hands off control. The handoff uses the UEFI <span style=”font-family: Courier New;”>LoadImage/StartImage services, so an AArch64 Linux kernel (which is itself a UEFI stub application) boots exactly the way the firmware would have booted it, but now gated behind a wolfBoot signature check.

The new aarch64_efi target is the direct sibling of wolfBoot’s existing x86_64_efi target. Because it relies only on UEFI Boot Services and touches no SoC-specific registers, a single wolfboot.efi binary is portable across AArch64 UEFI platforms instead of being tied to one board.

Validated on the Jetson Orin Nano

On the Orin Nano (Tegra234, Cortex-A78AE), we deployed wolfboot.efi to the SD card as the standard removable-media boot path (\EFI\BOOT\BOOTAA64.EFI) alongside a signed kernel image. The NVIDIA UEFI firmware auto-launches it, and from the debug console you can watch the whole verified-boot flow:

Kernel cmdline from cmdline.txt
Opening file: kernel.img
Verifying signature...done
Staging kernel...
EFI stub: Booting Linux Kernel...

wolfBoot verifies the signed NVIDIA L4T kernel, which then boots straight from the SD card to an Ubuntu 22.04 login prompt, no initrd required.

Just as importantly, tampering is caught: flip a byte in the signed image and wolfBoot refuses to boot it.

A complete RoT: UEFI Secure Boot

Verifying the kernel is only half of a trust chain, since something still has to verify wolfBoot itself. On the Orin we closed that gap by enrolling wolfBoot into UEFI Secure Boot. A small helper, tools/scripts/sign-efi-secureboot.sh, generates the PK/KEK/db keys and signs wolfboot.efi with sbsign; enrolling the db certificate through the Jetson’s UEFI setup menu makes the edk2 firmware verify wolfboot.efi before it is ever allowed to run.

With Secure Boot enforcing, we validated the chain both ways on hardware. The signed wolfboot.efi launches, verifies the kernel, and boots to the login prompt. Swap in an unsigned build and the firmware refuses to load it: no wolfBoot banner, no boot, a Security Violation. One subtlety worth knowing: once Secure Boot is on, wolfBoot’s own LoadImage of the kernel is also checked against db, so the kernel is signed twice (with the db key for the firmware’s LoadImage, and with wolfBoot’s key for wolfCrypt) and is trusted by both.

The end-to-end chain is now firmware → wolfBoot → Linux kernel, every link cryptographically verified. For a production device the firmware itself is locked down by burning the NVIDIA PKC/SBK fuses; we document that final step without performing it, keeping the development board unfused.

Measured boot into the NVIDIA fTPM

The Jetson firmware ships a TPM 2.0 (an OP-TEE Firmware TPM) exposed through the standard EFI_TCG2_PROTOCOL, and it already measures the early boot chain into PCRs. wolfBoot now extends that chain to the operating system: just before handoff it measures the verified kernel into a PCR with HashLogExtendEvent, the same consumer pattern a hardened U-Boot uses. The platform firmware and fTPM perform the hashing and the extend, so wolfBoot needs no TPM driver of its own.

The Orin console shows the measurement in the real hardware TPM:

TCG2: TPM present=1 activeBanks=0x6 banks=2
TCG2: measured kernel (43091976 bytes) into PCR 9

Both the SHA-256 and SHA-384 PCR banks are extended. An attestation service can later read that PCR together with the TCG2 event log to prove exactly which kernel wolfBoot verified and booted, turning verified boot into measured, attestable boot. It is a single build option (MEASURED_BOOT_TCG2=1) and is best-effort: on a platform with no firmware TPM it simply logs that and continues.

Build and try it

The aarch64_efi target is available in wolfBoot pull request #818.

Building is a one-time gnu-efi setup followed by a normal wolfBoot build:

./tools/scripts/build-gnu-efi-aarch64.sh
cp config/examples/aarch64_efi.config .config
make

That produces wolfboot.efi. You do not need hardware to experiment, since the included QEMU helper runs the whole flow under emulated AArch64 UEFI:

./tools/scripts/aarch64-efi-qemu.sh

The full step-by-step recipe for signing an L4T kernel and laying out the SD card lives in the NVIDIA Jetson Orin section of docs/Targets.md.

What’s next

With verified boot, UEFI Secure Boot, and measured boot all working on the Orin, the remaining items are production hardening and reach: burning the NVIDIA PKC/SBK fuses to lock the firmware RoT on a production unit, a full vendor-firmware replacement with tight integration to the hardware RoT, remote attestation built on the fTPM PCR measurements, and NVMe boot media in addition to microSD.

wolfBoot is dual-licensed under GPLv3 and a commercial license, and is FIPS-ready through wolfCrypt. The AArch64 UEFI target is available for review in pull request #818. If you are building verified boot on Jetson or any other AArch64 UEFI platform, we would love to hear from you, reach out to facts@wolfssl.com.

Download wolfSSL Now