On 9/30/21 8:23 AM, François Ozog wrote:
Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng...@gmail.com
<mailto:bmeng...@gmail.com>> a écrit :
Hi Heinrich,
On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt
<xypron.g...@gmx.de <mailto:xypron.g...@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.o...@linaro.org <mailto:francois.o...@linaro.org> | Skype: ffozog
