> 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.
