Hardening of U-Boot

U-Boot is the bootloader responsible for loading Bunker OS and Open World payloads. It sits after the hypervisor and is therefore a critical link in the Chain of Trust. Despite being signed as part of the boot image, due to its flexibility, it exposes a powerful command interpreter and supports a broad range of commands, introducing several avenues through which the second link of the CoT could be weakened if left unhardened.

The BCA reference build applies a set of U-Boot hardening modifications, integrated into the meta-bunker layer. These modifications are pre-applied to Bunker OS builds and are also applied to Open World builds by default through the same layer configuration.

Why Hardening Is Necessary

Even after the FSBL verifies U-Boot’s binary, U-Boot itself must not provide mechanisms that bypass the subsequent signature checks. An attacker with physical access to the board can connect to the serial console and interact with the U-Boot CLI if left open.

Hardening Features

Command Whitelisting

The U-Boot build exposes over 200 commands. When hardening is enabled, command execution is governed by a whitelist keyed to the device state (open versus closed). On a closed device only the minimal set of commands required to boot is permitted, plus a small number of diagnostic commands deemed safe. The lists are stored in U-Boot’s control device-tree blob (control DTB) and are configured at build time:

/ {
    chosen {
        bca,secure-boot {
            bootloader-commands {
                allow-open   = <CMD_CAT_ALL>;
                allow-closed = <CMD_CAT_ALL_SAFE>;
                deny-closed  = <CMD_CAT_ALL_UNSAFE>;
                needed       = <CMD_CAT_NEEDED>;
            };
        };
    };
};

On an open device all commands are available minus those explicitly marked unsafe. On a closed device only safe and strictly needed commands are allowed.

Exclusive Signed Software Execution (bootm protection)

The bootm command is required for booting but is general enough to execute unsigned images. When hardening is active, bootm is restricted to FIT images authenticated against the embedded public key. Alternative bootm invocation forms that bypass signature verification — such as direct sub-image notation — are blocked.

Self-overwriting Protection

Commands that load data into arbitrary RAM addresses can, in principle, be used to overwrite the running U-Boot code in memory. The hardening patches enforce that load destinations stay within a safe address window (0 to RAM_SIZE − 64 MiB), ensuring U-Boot itself cannot be overwritten via a crafted boot script. This is implemented via CONFIG_LMB and a BCA-specific load protection option configured in the meta-bunker U-Boot fragment.

CLI Access Prevention

When the device is in the closed state, access to the U-Boot interactive CLI is disabled by default, eliminating the serial-console attack vector entirely. The CLI remains available on open devices to allow eFuse programming during manufacturing. If a product requires CLI access even on closed devices, the enable-cli-when-closed property can be added to the control DTB.

Kernel Command-Line Protection

The kernel command line (bootargs) can significantly influence Linux behaviour — for example, by overriding the init binary. Because bootargs is constructed from U-Boot environment variables stored in flash, it is subject to offline tampering. The hardening solution embeds the fixed portion of the expected command line inside the signed FIT image as a device-tree overlay, and U-Boot validates the actual bootargs against it at runtime:

## Validation of bootargs succeeded.

If validation fails, U-Boot emits a warning and — on a closed device — halts the boot. On an open device the warning is printed and boot continues, enabling the developer to identify the correct value for the required bootargs variable (see Meta Layers Reference).

Enabling U-Boot Hardening in a Custom Build

Note

U-Boot hardening is activated automatically in the BCA reference design. The following applies only to teams integrating meta-bunker into a custom layer stack.

U-Boot hardening is activated when the bca-signed BitBake class is inherited (see Secure Boot). No additional configuration is required for standard BCA board configurations. To adjust the command whitelist or to enable CLI access on a closed device, provide a customised control DTB via the appropriate variable in your machine or distro configuration. Refer to Meta Layers Reference for the variable name and default path.