Driver model at UEFI runtime

[Bin Meng]

Hi Heinrich,

On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> Hello Simon,
>
> The EBBR specification requires that the UEFI SystemReset() runtime
> service is available to the operating system.
>
> Up to now this has been implemented by overriding function
> efi_reset_system() which is marked as __efi_runtime.
>
> Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM
> and the System Reset Extension for SBI on RISC-V. This has kept the
> number of implementations low. The only exceptions are:
>
> * arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs
> * arch/sandbox/cpu/start.c
>
> Bin has suggested in
> https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use
> reset drivers based on the driver model.
>
> Currently after ExitBootServices() the driver model does not exist anymore.
>
> When evaluating Bin's suggestion one has to keep in mind that after
> invoking ExitBootServices() most operating systems call
> SetVirtualAddressMap(). Due to the change of the address map all
> pointers used by U-Boot afterwards must be updated to match the new
> memory map.
>

Yeah, this was discussed 3 years ago:
https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken

> The impression that Ilias and I have is that keeping the driver model
> alive after SetVirtualAddressMap() would incur:
>
> * a high development effort
> * a significant code size increase
> * an enlarged attack surface
>
> For RISC-V it has been clarified in the platform specification that the
> SBI must implement the system reset extension. For ARMv8 using TF-A and
> PSCI is what ARM suggests.
>
> So for these architectures we do not expect a growth in the number of
> drivers needed.
>
> Ilias and my favorite would be keeping the design as is.
>
> What is your view on this?

Is U-Boot's UEFI loader implementation supposed to be the recommended
UEFI firmware on ARM and RISC-V on a production / deployment system?
Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we
expect to load grub.efi which chain-loads a kernel without
CONFIG_EFI_STUB? What do distributions normally do? What's our
position when compared to EDK II?

Regards,
Bin