Re: Driver model at UEFI runtime

From: "François Ozog" <francois.ozog@linaro.org>
To: Bin Meng <bmeng.cn@gmail.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	 Simon Glass <sjg@chromium.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>
Subject: Re: Driver model at UEFI runtime
Date: Thu, 30 Sep 2021 08:45:58 +0200	[thread overview]
Message-ID: <CAHFG_=UFNUN2jDmJHZ8ZXuZpyExx2tM93R0j6-LRV=XeaXhbyw@mail.gmail.com> (raw)
In-Reply-To: <CAEUhbmX0oa_rS-KjoJkSbgnxFRBXnUQUX+MX7xiQq=2_1zGSFw@mail.gmail.com>

Le jeu. 30 sept. 2021 à 08:38, Bin Meng <bmeng.cn@gmail.com> a écrit :

> On Thu, Sep 30, 2021 at 2:23 PM François Ozog <francois.ozog@linaro.org>
> wrote:
>
>>
>>
>> Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng.cn@gmail.com> a écrit :
>>
>>> Hi Heinrich,
>>>
>>> On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt <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 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?
>
Arm server boot is defined in SystemReady-SR.

> Does any board that ships EDK II with UEFI + DTB?
>
there are boards with EDK II with DTB (Socionext Synquacer has a boot menu
to select between ACPI and DT).

> Can we safely assume that U-Boot's UEFI loader is the reference
> implementation for UEFI + DTB on Arm?
>
yes: that is SystemReady-IR that Arm, Linaro and SoC vendors have made a
reality in the past year and a half.  The key benefit is non brickable with
anti rollback protection you get of all firmware through the UEFI capsule.
The UEFi capsule is complemented by an Arm architecture capsule through FFA
interface.
You will have a number os SystemReady sessions at the forthcoming Arm Dev
Summit.
You will also see VMWare supporting SystemReady-ES, and I am hopeful that
Andrei@VMware will also support SystemReady-IR.

>
>
>>
>>> 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
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog