Skip to content
FreeBSDDeep Dive Published Updated 5 min readViews unavailable

FreeBSD UEFI Secure Boot: Build Options, Trust Boundaries, and Verification

Separate firmware image authentication from FreeBSD loader and kernel checks, inspect the 15.1 build options, and test changes without risking a bootable host.

“Does FreeBSD support UEFI Secure Boot?” is too broad to be an operational answer. The useful questions are which EFI image firmware starts, what that firmware trusts, which verification features were compiled into that particular loader, and what the loader does with the kernel and modules afterward. Those are separate decisions at separate stages.

This guide uses the FreeBSD 15.1-RELEASE manuals and the releng/15.1 source option table. They establish that the source tree has relevant build options; they do not prove that a vendor or locally installed loader.efi was built with them, that firmware accepts it, or that a running kernel enforces a later policy.

Keep the verification layers distinct

UEFI firmware locates an EFI executable on the EFI System Partition and starts it. FreeBSD’s uefi(8) manual identifies loader.efi as the next stage, and the loader then loads and boots the kernel. When Secure Boot is enabled, UEFI image authentication is governed by firmware policy and its authorized and forbidden signature databases. A signed file alone is not evidence that a particular machine trusts its signer or has not revoked it.

FreeBSD 15.1 documents three related, but non-equivalent, build switches:

Layer FreeBSD evidence What the evidence does not establish
Firmware starts an EFI image UEFI firmware policy and the selected EFI path That later kernel or module loads are also checked
Loader verifies against UEFI certificates WITH_LOADER_EFI_SECUREBOOT builds loader support for verification based on certificates obtained from UEFI That a stock or vendor-installed loader contains this support, or which key set a machine accepts
Loader hashes/verifies loaded kernel and modules WITH_LOADER_VERIEXEC_VECTX enables this loader behavior and depends on WITH_LOADER_VERIEXEC A universal signature-enforcement policy for every module or every FreeBSD installation

WITH_LOADER_VERIEXEC itself depends on BearSSL and may require a larger loader image. WITH_LOADER_VERIEXEC_PASS_MANIFEST is another option: it passes a verified manifest to a kernel that must include a module able to parse it. These names describe build capabilities, not a single switch that automatically proves an end-to-end trust chain.

The pinned releng/15.1 option table is especially useful when reading defaults: BearSSL is in the default-no options, loader Veriexec defaults only when BearSSL is enabled, and EFI Secure Boot depends on loader Veriexec. That option resolution leaves this chain disabled under unmodified defaults. The dependency direction matters for a custom build: enabling WITH_BEARSSL also enables the dependent loader options unless explicitly disabled, whereas requesting EFI Secure Boot alone does not supply the missing BearSSL and Veriexec prerequisites. Inspect the resolved options in the exact build environment; do not assume either presence or absence in a vendor image without evidence about the exact binary and its build.

Audit the running system without changing it

Start by recording release and architecture, then identify the exact loader path used by the machine. The command below reads release identifiers; it does not show how every component was built:

freebsd-version -kru

The installed /boot/loader.efi may not be the file that firmware actually starts. Firmware boot entries, the fallback path on the EFI System Partition, architecture, and any vendor-specific path can differ. Use efibootmgr(8) and the EFI partition inventory to establish the path before drawing conclusions. Keep that inspection read-only; changing BootOrder or replacing an EFI file is a different operation.

On the candidate image, file can identify the binary format and sha256 can record a reproducible digest. FreeBSD also supplies uefisign(8):

file /boot/loader.efi
sha256 /boot/loader.efi
uefisign -Vv /boot/loader.efi

Interpret the last result narrowly. uefisign -V determines whether the PE file contains a signature; the manual explicitly says it does not verify that signature’s correctness. It cannot tell you whether firmware trusts the certificate, whether the image is revoked, or whether that image is the one the machine launched. Save the digest and tool output alongside the exact release and file path, not as a trust verdict.

If you control a source build, inspect its build inputs and the option-resolution output for the matching source revision. A current /etc/src.conf is only a clue: it may have changed since an image was built, and vendor builds may use a different configuration. Compare the configuration to the pinned source for the exact release rather than copying options from main or another release branch.

Test a changed trust policy in a disposable environment

Before experimenting, preserve the known-good EFI loader, boot entry, firmware recovery instructions, and out-of-band console path. Build and test the intended loader in a VM or spare machine whose architecture, UEFI implementation, Secure Boot mode, enrolled keys, and revocation database are known. An emulator is a useful repeatable test fixture, but passing there is not proof that the same image and key state work on different physical firmware.

Change one layer at a time: first establish which loader the firmware starts; then test that firmware’s signature decision; only then test any loader-side kernel or module verification. Keep an unsigned or known-good recovery path available during a lab exercise. Do not enroll or replace platform keys, modify db/dbx, or overwrite the only bootable loader on a remote production machine without an approved recovery plan and verified console access.

A defensible conclusion

Report the evidence in layers: “the firmware boot entry points to this image,” “this tool found an embedded signature,” “the release source offers these optional loader checks,” and “this tested build behaved this way with these firmware keys.” Avoid collapsing those statements into “FreeBSD Secure Boot is enabled.” FreeBSD 15.1’s build documentation is precise about optional support; the machine’s actual firmware state and exact loader build still need their own verification.

Related:

Sources:

Comments