bootstd: Support for distro specific EFI folders

[Heinrich Schuchardt]

On 11/19/23 01:43, Simon Glass wrote:
> 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?

The standardized way to define that meta-data are boot options.

Besides EFI/<vendor>/*.efi installers typically leave a 
/EFI/BOOT/BOOT<arch>.EFI on the ESP which U-Boot will pick up by default 
if no boot option is specified. If Armbian does not do this, it might be 
something to fix there.

Best regards

Heinrich