[RFC PATCH 1/1] efi_loader: get rid of ad-hoc EFI subsystem init

[Simon Glass]

Hi Heinrich,

On Fri, 20 Jan 2023 at 13:36, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 1/20/23 20:19, Simon Glass wrote:
> > Hi,
> >
> > On Fri, 20 Jan 2023 at 06:03, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> Am 20. Januar 2023 13:31:19 MEZ schrieb Ilias Apalodimas <ilias.apalodimas at linaro.org>:
> >>> Up to now the EFI subsystem was left out of the main U-Boot init
> >>> process.  This has led to various hacks over the years, with the most
> >>> notable one being sprinkling around the efi init call to various places
> >>> such as U-Boot commands, the early boot code etc.
> >>>
> >>> Since EFI has it's own Kconfig option and people can remove it, let's
> >>> wire up the EFI init call on an event for EVT_MAIN_LOOP.
> >>>
> >>> This will also get rid of ad-hoc code in the main event loop, which was
> >>> trying to initialize the subsystem early and perform capsule updates.
> >>>
> >>> TODO:
> >>> - The efi_tcg protocol implicitly initializes the TPM, as a result
> >>>   some of the tpm selftests will fail with the RFC.  If everyone
> >>>   agrees that this is a good idea, I'll clean up the TPM hacks as well
> >>> - We  still need to run capsule updates on the main_loop() code since
> >>>   in some cases (e.g sandbox) we need preboot commands.
> >>> - wider tests, I've only run QEMU for now
> >>>
> >>> Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> >>
> >>
> >> In case of efi_init_obj_list() failing we should still reach the U-Boot console but each of the EFI commands should abort early.
> >>
> >> Please, put the Kconfig related capsule change into a separate patch.
> >>
> >> Otherwise looks good to me.
> >>
> >
> > I am OK with this change too.
> >
> > Two points from my side:
> >
> > 1. The main loop capsule update is (still) a mistake, unfortunately.
> > It should be a command which is run on boot. For sandbox testing, that
> > command should be run *without* rebooting. I am sure I asked for that
>
> Capsule updates must run outside of any command as this is required by
> the UEFI specification.

What do you mean? Does the specification mention U-Boot commands?

>
> Capsule updates require a reboot and the sandbox must behave as a
> regular system so that we can run the same tests on all systems.

How can I get you past this thinking? We need to 'design for test'.
The current test is a mess, sorry. Perhaps we could have a call to go
through it?

>
> > at the time but for various reasons it didn't happen. Please can you
> > make that change also?
> >
> > 2. EFI should not be maintaining its own separate data structures, but
> > should keep them attached to driver model. They should be created as
> > needed, dynamically, not all at the start. Is anyone looking at this?
> > I am happy to help suggest initial target for this refactoring.
>
> We have started with such a link for block devices. Once those block
> devices are really UEFI compliant we should refactor the other devices
> currently supported by EFI sub-system:
>
> UART, network, RNG, video, TPM.
>
> Some initialization like setting up UEFI variables will not have any
> equivalence in the driver model.

One way to handle that is to:

- set up 'global' EFI structures attached to an EFI uclass
- set up 'per device' EFI structures when the device is bound or probed

Regards,
Simon