Hardening U-Boot for Production
U-Boot brings up most embedded Linux devices, and in production it is frequently left exactly as it was during development: an open console, an editable environment, and no signature checking. Any one of those hands an attacker the device. Here is how to lock U-Boot down before a product ships.
Why the Bootloader Is the Prize
U-Boot decides what runs. An attacker who reaches its prompt can change the boot arguments, load a different kernel, or drop straight to a root shell by appending init=/bin/sh. None of the protections in the operating system matter if the bootloader will hand control to anything.
Lock the Console and the Delay
The first job is to remove the interactive window. A non-zero boot delay with a known stop key is an open invitation:
# in production these come from the build config
setenv bootdelay 0
saveenv
Require Verified Boot
With FIT signature support enabled, U-Boot checks a signature over the image before booting it. A tampered image is refused:
bootm 0x80000000
## Loading kernel from FIT Image at 80000000 ... Verifying Hash Integrity ... sha256,rsa2048:dev+ OK Booting kernel ...
The OK on the signature line is the control working. Without CONFIG_FIT_SIGNATURE, that check does not happen and any image boots.
Three U-Boot Exposures
The three issues that turn a bootloader into a backdoor:
Shipping a Locked Bootloader
Disable or password-protect the console, set the boot delay to zero, enable FIT signature verification, strip commands you do not need, and protect the environment so bootargs cannot be rewritten. The production bootloader should do exactly one thing: verify and boot the real image.
Where This Fits
Reviewing bootloader configuration and proving that console access and unsigned images are blocked is part of a product security assessment. That review is the kind of work we do at Berkner Tech.