[PATCH 09/16] efi_loader: imply FAT, FAT_WRITE

AKASHI Takahiro
2020-04-02T01:34:15Z

Hi Mark,

On Wed, Apr 01, 2020 at 07:56:31PM +0200, Mark Kettenis wrote:
> > Date: Wed, 1 Apr 2020 09:31:03 +0900
> > From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >
> > On Tue, Mar 31, 2020 at 10:20:17AM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 31 Mar 2020 16:44:34 +0900
> > > > From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > >
> > > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote:
> > > > > On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote:
> > > > > > On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote:
> > > > > > > The UEFI spec requires support for the FAT file system.
> > > > > > >
> > > > > > > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > > > > > > ---
> > > > > > > lib/efi_loader/Kconfig | 2 ++
> > > > > > > 1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > > > > index 9890144d41..e10ca05549 100644
> > > > > > > --- a/lib/efi_loader/Kconfig
> > > > > > > +++ b/lib/efi_loader/Kconfig
> > > > > > > @@ -15,6 +15,8 @@ config EFI_LOADER
> > > > > > > select HAVE_BLOCK_DEVICE
> > > > > > > select REGEX
> > > > > > > imply CFB_CONSOLE_ANSI
> > > > > > > + imply FAT
> > > > > > > + imply FAT_WRITE
> > > > > >
> > > > > > Obviously, this *imply* doesn't enforce enabling FAT.
> > > > > > If it is absolutely necessary, another measure should be taken.
> > > > >
> > > > > If somebody wants to minimize the U-Boot size it might be necessary to
> > > > > do without FAT_WRITE or FAT support.
> > > >
> > > > If so, Get/SetVariable won't be supported even in boot time
> > > > with your patch applied. It is not practical for almost all users.
> > >
> > > I *strongly* disagree with that statement. Most users don't care
> > > about U-Boot providing a full EFI implementation. They just want to
> > > boot their OS. The basic EFI support in U-Boot is good enough for
> > > that and for OpenBSD and some Linux distros on arm/arm64 this is the
> > > only bootpath that works. If adding more code leads to board
> > > maintainers disabling EFI support this isn't helpful.
> >
> > Okay, so can you please describe the minimum set of functionality
> > for you? Without that, the discussion will not be fair.
>
> For OpenBSD/arm and OpenBSD/amr64 we adopted the UEFI interfaces in
> u-boot early on, even before most Linux distros did. As a result our
> requirements are very minimal:

Thank you for your quick feedback.
As I'm not familiar with OpenBSD things, this information gives me
much better view/understandings.

Just from my curiosity, let me ask some questions.

> Our bootloader uses the folowing boot services:

You don't reply on any features from "EFI Boot Manager,"
including BootXXXX variables, do you?

> - HandleProtocol()
> - AllocatePages()
> - FreePages()
> - LocateHandle()
> - LocateHandleBuffer()
> - LocateProtocol()
> - CreateEvent()
> - SetTimer()
> - WaitForEvent()
> - CloseEvent()
> - GetMemoryMap()
> - SetWatchdogTimer()
> - Exit()
>
> runtime services:

+ load_image/start_image, obviously?

> - ResetSystem()
>
> and protocols:
>
> - EFI_LOADED_IMAGE_PROTOCOL
> - EFI_DEVICE_PATH_PROTOCOL
> - EFI_BLOCK_IO_PROTOCOL
> - EFI_GRAPHICS_OUTPUT_PROTOCOL
> - EFI_RNG_PROTOCOL
> - EFI_SIMPLE_NETWORK_PROTOCOL
> - EFI_PXE_BASE_CODE_PROTOCOL

What about EFI_FILE_PROTOCOL and/or EFI_FILE_LOAD_PROTOCOL?

Don't you have the assumption that there must be any EFI system
partition (and file system) on your boards?

-Takahiro Akashi

> Obviously the last four are only used if there is actual hardware to
> support these protocols. But I'd consider them non-optional if such
> hardware exists.
>
> Our kernel only uses a couple if runtime services:
>
> - SetVirtualAddressMap()
> - GetTime() (optional)
> - SetTime() (optional)

As you might know, I'm working on UEFI secure boot for U-Boot.
Does OpenBSD support any kind of secure boot?
If so, is it based on UEFI feature (in that case, UEFI variables are
mandatory) or do you have your own solution?

Thanks,
-Takahiro Akashi

> Cheers,
>
> Mark