[systemd-devel] Prevent firmware from falling back to next EFI boot option on secure boot failure?

[Daniel Harms]

Hello,

We are doing some experiments with booting self-signed Unified Kernel
Images (UKIs) using systemd-boot.  Our eventual use-case is edge/IoT
devices, so no interactive user will be present for most OS upgrade
flows.

In doing some testing on the boot option fallback features (in a
vmware vm) we’ve run into a snag—when we set up an unsigned UKI as the
first option and a properly signed UKI as the second option,
systemd-boot appears to attempt to boot the unsigned one (as
expected), the system reports a security violation, but then the
firmware kicks us to the next boot option.  This means that
systemd-boot never has the chance to try the second (good) option, and
in our case the vm gets kicked into trying PXE boot because that
happens to be the next option.  The ultimate use case we have in mind
will include unattended UKI updates, so this represents a problem for
us (we’d like systemd-boot to be able to boot into the “old” UKI if
the new one isn’t properly signed).

We’re using systemd 249.11—ubuntu3.4 from a clean install of Ubuntu
22.04.  We plan to try with systemd v252 as well as on real hardware,
but I wanted to reach out and see if this is a known “issue” (I
understand systemd-boot might be doing the right thing here) and if
anyone has a workaround or suggestions for getting secure boot
problems from the boot options to kick us back to systemd-boot.

Thanks,

--Daniel