On Wed, Dec 6, 2023 at 9:31 AM Heinrich Schuchardt
<heinrich.schucha...@canonical.com> wrote:
>
> On 05.12.23 07:23, Masahisa Kojima wrote:
> > Hi Heinrich,
> >
> > On Tue, 5 Dec 2023 at 11:38, Heinrich Schuchardt
> > <heinrich.schucha...@canonical.com> wrote:
> >>
> >> * Only generate removable media entries for EFI system partitions.
> >> * Only offer EFI system partitions for boot options in the eficonfig
> >> command.
> >>
> >> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> >> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
> >> Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
> >> ---
> >> cmd/eficonfig.c | 6 ++++--
> >> lib/efi_loader/efi_bootmgr.c | 3 ++-
> >> 2 files changed, 6 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> >> index 34a59cb15d..c066b28b6b 100644
> >> --- a/cmd/eficonfig.c
> >> +++ b/cmd/eficonfig.c
> >> @@ -626,8 +626,10 @@ static efi_status_t eficonfig_select_volume(struct
> >> eficonfig_select_file_info *f
> >> efi_handle_t *volume_handles = NULL;
> >> struct efi_simple_file_system_protocol *v;
> >>
> >> - ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> &efi_simple_file_system_protocol_guid,
> >> - NULL, &count, (efi_handle_t
> >> **)&volume_handles);
> >> + /* Find all EFI system partitions */
> >> + ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> + &efi_system_partition_guid,
> >> + NULL, &count, &volume_handles);
> >
> > UEFI specification v2.10 section '3.5 Boot Mechanisms' says
> > "EFI can boot from a device using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the
> > EFI_LOAD_FILE_PROTOCOL."
> >
> > So in my understanding of the UEFI spec, I think
> > efi_simple_file_system_protocol_guid
> > is correct here.
> >
> >> if (ret != EFI_SUCCESS) {
> >> eficonfig_print_msg("No block device found!");
> >> return ret;
> >> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >> index 48153bd5ff..9e84391186 100644
> >> --- a/lib/efi_loader/efi_bootmgr.c
> >> +++ b/lib/efi_loader/efi_bootmgr.c
> >> @@ -1047,8 +1047,9 @@ efi_status_t
> >> efi_bootmgr_update_media_device_boot_option(void)
> >> efi_handle_t *volume_handles = NULL;
> >> struct eficonfig_media_boot_option *opt = NULL;
> >>
> >> + /* Find all EFI system partitions */
> >> ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> >> -
> >> &efi_simple_file_system_protocol_guid,
> >> + &efi_system_partition_guid,
> >
> > In EDK II reference implementation[0], it enumerates all
> > block_io_protocol devices
> > and eliminates logical partitions.
> > Should we do the same? If yes, I can prepare the patch on this.
>
> This is what the boot options look like on an EDK II system:
>
> $ efibootmgr -v
> BootCurrent: 000D
> Timeout: 3 seconds
> BootOrder:
> 000D,000B,000C,0003,0004,0005,0006,0007,0008,0009,000A,0000,0001,0002
> Boot0000* UiApp
> FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
> Boot0001* helloworld
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,000054f20000000000)/Sata(1,65535,0)/HD(1,GPT,40c323d0-6b76-47c4-bc82-e05bf5d23c9f,0x2000,0x200000)/File(\helloworld.efi)h.e.l.l.o.
> .w.o.r.l.d...
> Boot0002* UEFI Crucial_CT128M550SSD1 14270C7CFEFE
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,000054f20000000000)/Sata(1,65535,0)N.....YM....R,Y.
> Boot0003* UEFI eMMC Device
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,00006ef00000000000)/eMMC(0)/Ctrl(0x0)N.....YM....R,Y.
> Boot0004* UEFI eMMC Device 2
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,00006ef00000000000)/eMMC(0)/Ctrl(0x1)N.....YM....R,Y.
> Boot0005* UEFI eMMC Device 3
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,00006ef00000000000)/eMMC(0)/Ctrl(0x2)N.....YM....R,Y.
> Boot0006* UEFI PXEv4 (MAC:000000000001)
> MAC(000000000001,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
> Boot0007* UEFI PXEv4 (MAC:000000000002)
> MAC(000000000002,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
> Boot0008* UEFI PXEv4 (MAC:000000000003)
> MAC(000000000003,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
> Boot0009* UEFI PXEv4 (MAC:000000000004)
> MAC(000000000004,1)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y.
> Boot000A* UEFI Shell
> FvVol(5eda4200-2c5f-43cb-9da3-0baf74b1b30c)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
> Boot000B* UEFI HL-DT-ST DVDRAM GTC0N
> VenHw(0d51905b-b77e-452a-a2c0-eca0cc8d514a,000054f40000000000)/Sata(1,65535,0)N.....YM....R,Y.
> Boot000C* ubuntu
> HD(1,GPT,5a1ba4fc-f9b4-4da2-b5e1-065e9cd10e3a,0x800,0x100000)/File(\EFI\ubuntu\grubaa64.efi)
> Boot000D* grub
> HD(1,GPT,5a1ba4fc-f9b4-4da2-b5e1-065e9cd10e3a,0x800,0x100000)/File(\EFI\grub\shimaa64.efi)
> Boot1001* helloworld
> HD(1,GPT,40c323d0-6b76-47c4-bc82-e05bf5d23c8f,0x2000,0x200000)/File(helloworld.efi)
>
> As you described autogenerated boot options are on block device level
> irrespective of the existence of an ESP.
>
> EDK II does not to care if /EFI/BOOT/BOOT<ARCH>.EFI is on a partition
> with the ESP partition type.
>
> We should try to mimic the EDK II behavior.
I believe the UEFI spec allows VFAT partition type as well ESP
partition type. For example a lot of Raspberry Pis won't load their
firmware of a ESP partition type but will off VFAT even though they
are essentially the same thing.
