Driver model at UEFI runtime

[Ilias Apalodimas]

On Thu, 30 Sept 2021 at 09:38, Bin Meng <bmeng.cn at gmail.com> wrote:
>
> On Thu, Sep 30, 2021 at 2:23 PM François Ozog <francois.ozog at linaro.org> wrote:
>>
>>
>>
>> Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng.cn at gmail.com> a écrit :
>>>
>>> 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?
>>
>> For Arm: yes, that is SystemReady spec.
>
>
> How about EDK II? Is EDK II supposed to be used in the server environment where UEFI + ACPI is the way to go?
>

Yes ACPI pretty much means EDK2.  Specifically for Arm
SystemReady-ES/SR (embedded server ready and server ready), require
ACPI.  Boards passing that certification today use EDK2.

> Does any board that ships EDK II with UEFI + DTB?

The Socionext SynQuacer box is the only board I know off, that works
with EDK2 and can use either DT or ACPI.

> Can we safely assume that U-Boot's UEFI loader is the reference implementation for UEFI + DTB on Arm?

There's even more to that. EDK2 is bound to the PI spec as well as the
UEFI spec.  U-Boot is a UEFI implementation that doesn't need to
adhere to that.

Regards
/Ilias
>>>
>>>
>>> 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.
>>>
>>> What's our
>>> position when compared to EDK II?
>>
>> 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 enhance security and boot time. Note: Since kernel 5.10, initrd can be measured (with TPM) when loaded by efi-stub.
>
>
> Regards,
> Bin