bootstd: Support for distro specific EFI folders

[Simon Glass]

Hi Heinrich,

On Sat, 18 Nov 2023 at 15:52, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> On 11/18/23 22:28, Shantur Rathore wrote:
> > Hi Heinrich,
> >
> > On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt
> > <heinrich.schuchardt at canonical.com> wrote:
> >>
> >> On 11/16/23 19:45, Shantur Rathore wrote:
> >>> On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt
> >>> <heinrich.schuchardt at canonical.com> wrote:
> >>>>
> >>>> On 11/16/23 17:52, Shantur Rathore wrote:
> >>>>> Hi Simon,
> >>>>>
> >>>>> Currently bootstd - bootmethod_efi only looks for the default
> >>>>> bootxx64.efi in /EFI/boot folder only.
> >>>>> Generally many distros end up putting their bootloaders in
> >>>>> EFI/<distro> folders like EFI/ubuntu and EFI/debian etc.
> >>>>>
> >>>>> In x86 worlds, the NVRAM is modified and new boot entries are added to
> >>>>> support these but in the U-boot world the NVRAM variables are
> >>>>> read-only.
> >>>>
> >>>> I guess you are referring to UEFI boot options. These typically are not
> >>>> stored in non-volatile RAM but on a SPI flash device.
> >>>>
> >>>
> >>> Thanks for correcting me.
> >>>
> >>>>>
> >>>>> What would be the best way to implement this?
> >>>>>
> >>>>> I was thinking of having a "efi_prefixes" environment variable which
> >>>>> can be set to "ubuntu debian centos" etc and bootmethod_efi can try
> >>>>> all of them. Will bootmethod_efi be able to support multiple entries (
> >>>>> thinking of multiboot ) ?
> >>>>
> >>>> On my laptop I have:
> >>>>
> >>>> EFI/Microsoft/Boot/bootmgr.efi
> >>>> EFI/Microsoft/Boot/memtest.efi
> >>>> EFI/Boot/bootx64.efi
> >>>> EFI/Boot/fbx64.efi
> >>>> EFI/Boot/mmx64.efi
> >>>> EFI/debian/shimx64.efi
> >>>> EFI/debian/grubx64.efi
> >>>> EFI/debian/mmx64.efi
> >>>> EFI/debian/fbx64.efi
> >>>> EFI/ubuntu/grubx64.efi
> >>>> EFI/ubuntu/shimx64.efi
> >>>> EFI/ubuntu/mmx64.efi
> >>>>
> >>>> Obviously each installed operating system provides multiple EFI binaries
> >>>> and non uses the fallback file name BOOT<ARCH>.EFI. A value "ubuntu
> >>>> debian centos" would not be able to describe which file you are looking
> >>>> for.
> >>>>
> >>>> We already have the U-Boot command line eficonfig and efidebug commands
> >>>> to set up UEFI boot options which can describe which EFI binary to load
> >>>> and which command line to pass to it. These are considered by the
> >>>> existing boot flows.
> >>>
> >>> So, I am building a new RockPro64 based cluster and using Canonical
> >>> MAAS to set them up automatically, booting them up using DHCP and
> >>> installing them over the network.
> >>> I configured an Armbian image using Packer to be compatible with MAAS
> >>> and it happily installs it. As part of installation process, a
> >>> grub-install is run which installs the grub efi,
> >>> this EFI ends up in EFI/debian instead of expected EFI/boot.
> >>> To be able to make it boot, I have to add commands to move it to
> >>> EFI/boot. I am trying to find a way in U-Boot that would allow me to
> >>> skip this step.
> >>> With eficonfig if I understand correctly, it would need manual
> >>> intervention to create boot entries.
> >>>
> >>>>
> >>>> If you are installing the shim-signed package on Ubuntu, the EFI boot
> >>>> option for Ubuntu is set up by EFI/BOOT/BOOT<ARCH>.EFI using the content
> >>>> of EFI/ubuntu/BOOT<ARCH>.CSV. This is done before ExitBootServices() and
> >>>> therefore should work with current U-Boot.
> >>>>
> >>>> Patches are pending upstream to make EFI variables writable from Linux
> >>>> if they are stored in the RPMB partition in the eMMC. See this series:
> >>>>
> >>>> https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.kojima@linaro.org/
> >>>>
> >>>
> >>> Would it be possible to save it in SPI Flash as the U-Boot environment ?
> >>
> >> Currently this is not supported by U-Boot.
> >>
> >> The U-Boot environment variables can be stored in lots of different
> >> places SPI flash is only one of these. But none of these locations is
> >> protected from OS access which would be preferable for UEFI variables
> >> for security reasons.
> >>
> >> To support boards without eMMC the right way forward would be writing a
> >> new implementation of the OP-TEE standalone MM which writes the
> >> variables to SPI flash instead of the RPMB partition and ensures that
> >> the SPI flash' MMIO registers are protected against access from the
> >> non-secure world.
> >
> > Thanks for explaining this to me.
> > This seems like a long way to go, for now what would be an acceptable
> > solution, some options are
> >
> > 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu
> > debian") variable which is ready by bootmeth_efi and used as
> > efi/<efi_prefix> instead of efi/boot.
> > 2. Improve bootmeth_efi to find all bootxxxx.efi in efi/ folder and
> > present all them as bootflows to bootstd.
>
> As mentioned in a prior mail ubuntu/bootxxxx.efi and debian/bootxxxx.efi
> don't exist. I would prefer not to add any distro specific stuff in
> upstream U-Boot. Instead we will continue to drive what Linaro has
> suggested to improve U-Boot EFI variables support in Linux.

Is there any metadata in the distro which U-Boot could read to find
out where the EFI file is?

Regards,
Simon