bootstd: Support for distro specific EFI folders

[Heinrich Schuchardt]

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.

Best regards

Heinrich