[PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist

[Ilias Apalodimas]

Hi Heinrich

On Mon, 3 Apr 2023 at 19:31, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 3. April 2023 16:17:42 MESZ schrieb Tom Rini <trini at konsulko.com>:
> >On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote:
> >> On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote:
> >> > Hi Tom,
> >> >
> >> > On Sat, 1 Apr 2023 at 07:02, Tom Rini <trini at konsulko.com> wrote:
> >> > >
> >> > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote:
> >> > >
> >> > > > The current EFI implementation has a strange quirk where it watches
> >> > > > loaded files and uses the last-loaded file to determine the device that
> >> > > > is being booted from.
> >> > > >
> >> > > > This is confusing with bootstd, where multiple options may exist. Even
> >> > > > loading a device tree will cause it to go wrong. There is no API for
> >> > > > passing this information, since the only entry into booting an EFI image
> >> > > > is the 'bootefi' command.
> >> > > >
> >> > > > To work around this, call efi_set_bootdev() for EFI images, if possible,
> >> > > > just before booting.
> >> > > >
> >> > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> >> > >
> >> > > Shouldn't this all be a simple wrapper around the EFI Standard
> >> > > BootDeviceOrder or whatever that's called?
> >> >
> >> > I think you are referring to boot manager, which isn't used here. This
> >> > is replicating the existing distroboot functionality in standard boot.
> >>
> >> The distroboot functionality *was* trying to behave like the EFI spec
> >> expects the bootmanager to behave.  Unfortunately I haven't had time to
> >> review the distroboot patches closely, but back when this started, my point
> >> was that EFI doesn't need anything.  Whenever the EFI flow is added bootstd
> >> should 'just' call the bootmanager.
>
> Distroboot used to load the devicetree from a default location too.
>
> This makes good sense on many boards but poses a problem for secure boot.

Yes ideally you want to load the DTB that comes along with u-boot
since it's implicitly verified by the device chain of trust.  However
we can now measure the dtb that gets installed on a config table.

Regards
/Ilias
>
> @Ilias, we need to evaluate this.
>
> Regards
>
> Heinrich
>
> >
> >Yes, this. We're trying make things cleaner overall, so the EFI portion
> >of bootstd distro boot should just be "call EFI bootmanager" as that has
> >a well defined standard way to specify what devices to try in what
> >order.
> >