[PATCH 3/3] efi_loader: disk: add EFI_PARTITION_INFO_PROTOCOL support

[Peter Robinson]

> > >> The project is https://gitlab.com/CentOS/automotive/src/ukiboot and reads
> > >> UKI (https://uapi-group.org/specifications/specs/unified_kernel_image)
> > >> images from raw data partitions. Just like ABL reads Android Boot images.
> > >>
> > >> > Are you planning to add it to the EBBR specification?
> > >> >
> > >>
> > >> I haven't thought about it before but I also didn't know that u-boot had
> > >> this requirement. Probably it should be documented somewhere to make it
> > >> more clear? Maybe I didn't look enough but didn't find a doc in the repo.
> > >
> > > We are not strictly and only EBBR requirements, if there is good reason
> >
> > That's good to know. Heinrich's answer seemed to imply that u-boot was
> > limited to EBBR requirements.
>
> It's one of the main users, yes, but it shouldn't be seen as *only* for
> that.

Also to note that EBBR is a living spec and can evolve, typically the
way we've done that historically is to have an implementation, or at
least patches, in U-Boot first to prove out the idea before putting
something in the spec so IMO this is the right way to go about this.

> > > to add more features (and tests). But Heinrich's follow-up question is
> >
> > Oh, I missed the lib/efi_selftest directory. I'll see to add a test then.
>
> Thanks.

Yes, the lack of tests was the first thing I noticed on the patches ;-)

> > > quite important. I feel like there's already a half dozen offerings of
> > > A/B update that works within UEFI.
> > >
> >
> > I just brought the A/B boot protocol used by ukiboot because I was asked
> > how I was using the EFI_PARTITION_INFO_PROTOCOL. But I'm not proposing to
> > add a new A/B update mechanism for u-boot, just to implement an existing
> > EFI protocol...
>
> Yes, this was more a lament for the ecosystem as a whole really. The
> concept of A/B(/Golden) with various security features is pretty old at
> this point, there's many implementations. I wish there was not "here is
> yet another" in the space.
>
> But regardless, we should aim to have U-Boot be able to be used with it.
> Otherwise my crystal ball says that a few years down the line it'll be
> hard to use Fedora-IoT-distro on common-device with U-Boot.

There's a basic concept of a fallback with the UEFI bootnext bits but
yes, if UEFI actually had the ability to deal with proper A/B we
wouldn't need a dozen different ways to do it, sigh, of course there's
some harder things that also need to be addressed like changes for
signing keys etc.

The other initial feedback I would ask is around a Kconfig to make it
optional, will everyone want/need it, what's the size impact?

Cheers,
Peter