bootstd: Support for distro specific EFI folders

[Shantur Rathore]

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.

Kind regards,
Shantur