On 9/30/21 13:31, Mark Kettenis wrote:
From: François Ozog <francois.o...@linaro.org>
Date: Thu, 30 Sep 2021 08:23:34 +0200
Le jeu. 30 sept. 2021 à 07:12, Bin Meng <bmeng...@gmail.com> a écrit :
Hi Heinrich,
On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt <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 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.
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.
One major attraction of using the UEFI boot flow on non-x86
architectures is that it allows OS distributions to use nearly
identical logic for installing themselves as on a x86 systems. And
as a result the user experience is largely the same.
I only have basic understanding of how the Linux EFI boot stub works
in practice, but I think it means that the Linux kernel you want to
boot has to live on a filesystem that can be accessed by the UEFI
firmware. And that pretty much means it has to live on a VFAT
filesystem, which is undesirable from a Linux distro perspective I'd
say. It also means that you have to rely on the EFI boot manager to
switch between kernels, which significantly changes the user
experience.
The Linux EFI stub does not access media and it does not care about the
location from where it was loaded.
The UEFI specification requires support for FAT but does not disallow
supporting further file systems. It might be seen as a deficiency of EDK
II that it only supports FAT and firmware filesystems.
U-Boot can load the kernel, initrd, and fdt from any supported device
irrespective of the boot method. When using UEFI boot options we
currently only support block devices. We do not yet support UEFI boot
options for loading from the network.
Best regards
Heinrich
