Secure boot enabled systems booting in user mode are unable to boot default bootloader in flasher images

[jakogut]

Secure boot enabled systems can enroll a provisioning key (PK), key exchange key (KEK), and key database (db, dbx) for whitelisted/blacklisted binaries to boot respectively.

Flasher images ship both an insecure bootloader image that does not validate signatures of modules, configuration, and binaries, as well as a secure bootloader image that does. Only the hash of the secured bootloader image is present in the db, so a system booting in user mode with keys enrolled will only boot the secured bootloader.

When flashing a system in setup mode, the insecure bootloader image is loaded from the EFI system partition (ESP) at the default path for the platform (/EFI/BOOT/bootx64.efi for x86-64). When the flasher runs, it attempts to enroll keys automatically using efi-updatevar. If this succeeds, the next boot will be in user mode. The firmware will verify the bootloader, the bootloader will verify configs, modules, and binaries (including the kernel and initramfs), and the kernel will boot in lockdown mode, verifying module signatures.

If the flasher is unable to automatically enroll keys due to a firmware quirk or inability to enter UEFI secure boot setup mode, keys may need to be enrolled manually. The process for doing this is firmware and platform specific, but generally the PK, KEK, and db keys from the flasher boot partition (/balena-keys) need to be manually enrolled in the setup menu.

After doing this, the system should boot next in user mode, and will not boot binaries that do not validate against the key database. This will prevent the flasher image from booting, as the default EFI binary path will not be present in db.

A workaround for this is to modify the flasher boot media to move the secure bootloader variant to the default EFI bootloader path.

More information on secure boot keys and behavior here.