Re: Prevent firmware from falling back to next EFI boot option on secure boot failure?

[Daniel Harms <jdharms@xxxxxxxxx>]

Lennart,

That is how we're hoping it should work, so it's good to hear.  I
suppose I'm not sure that it's the firmware driving this process--I
just assumed because I know that the UEFI spec has verbiage requiring
EFI boot managers to try next options in case of certain failure
cases.  I think you're probably right in that sd-boot *should* be able
to continue onwards down the list.

We're seeing the following error message in red text:

----------------

Error loading \EFI\Linux\linux-5.15.0-unsigned.efi: Security Policy Violation

Failed to execute [entry config name]
(\EFI\Linux\linux-5.15.0-unsigned.efi): Security Policy Violation

------------

What I believe is happening based on these messages is that
image_start() is returning an error here:
https://github.com/systemd/systemd/blob/v252/src/boot/efi/boot.c#L2747
and the `goto out;` is being executed, ending/preventing any looping
over boot options.

If this is a bug, I'd be willing to attempt a pull request submission
if a suggested fix is given.  Overall we like the functionality
sd-boot provides and the integration with systemd, but this is likely
a hard requirement for our use case.

Thanks,

--Daniel

On Wed, Nov 23, 2022 at 11:04 AM Lennart Poettering
<lennart@xxxxxxxxxxxxxx> wrote:
>
> On Mi, 23.11.22 10:22, Daniel Harms (jdharms@xxxxxxxxx) wrote:
>
> > 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.
>
> Hmm, are you sure this is the firmware? Normally a security violation
> should just be returned as an error to sd-boot, and sd-boot should be
> able to pick the next option then. Not entirely sure this works
> correctly though. There might be a bug lurking somewhere.
>
> it's simply not a case we regular test for. But it should be a case
> that just works.
>
> Lennart
>
> --
> Lennart Poettering, Berlin