Re: Driver model at UEFI runtime

[Heinrich Schuchardt <xypron.glpk@gmx.de>]

On 9/30/21 8:23 AM, François Ozog wrote:
>
>
> Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng.cn@gmail.com
> <mailto:bmeng.cn@gmail.com>> a écrit :
>
>     Hi Heinrich,
>
>     On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt
>     <xypron.glpk@gmx.de <mailto:xypron.glpk@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
>     <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
>     <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?
>
> For Arm: yes, that is SystemReady spec.

For RISC-V it is required by the RISC-V platform specification.

>
>
>     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?
>
> all paths should be possible , and the shim.efi is to be supported too.
> With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In
> other words I don’t see grub.efi booting a non config_efi_stub.
>
>     What do distributions normally do?
>
> At least Red Hat made it clear at multiple Linaro Connect that they want
> standards, and SystemReady is one that makes the life of embedded
> distros easy.
> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot.

For Fedora see
https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description

SUSE started the UEFI implementation to boot on all architectures in the
same way. The current ARM and RISC-V images uses UEFI.

Debian and Ubuntu install for booting via GRUB if the installer is
invoked via UEFI. A fallback solution using the legacy Linux entry point
exists.

For BSD the only way to boot on ARM is via UEFI.

>
>     What's our
>     position when compared to EDK II?

U-Boot implements only a subset of UEFI defined in the EBBR specification.

For servers you need a larger scope which is offered by EDK II. This is
required both by the RISC-V platform specification as well as the ARM
SystemReady ServerReady profile.

The number of boards supported by upstream EDK II is very low. But
proprietary firmware based on EDK II exists.

>
> the typical distro boot flow is not the most efficient and drags concept
> dating where the Microsoft certs had to be part of the picture. A direct
> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path
> (grub), avoids convoluted platform cert management (shim) and just

This is why U-Boot supports UEFI boot options specifying both a binary
as well as an initial RAM disk.

Best regards

Heinrich

> enhance security and boot time. Note: Since kernel 5.10, initrd can be
> measured (with TPM) when loaded by efi-stub.
>
>
>
>     Regards,
>     Bin
>
> --
>
> François-Frédéric Ozog | /Director Business Development/
> T: +33.67221.6485
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
>
>