[ipxe-devel] [PATCH] [efi] make load file protocol optional

[Laszlo Ersek]

On 02/12/15 15:55, Michael Brown wrote:
> On 12/02/15 14:41, Laszlo Ersek wrote:
>> 1.5 After shim.efi is loaded (using EFI_LOAD_FILE_PROTOCOL, which
>>      internally relies on EFI_PXE_BASE_CODE_PROTOCOL), shim.efi tries to
>>      load further files, like grub<ARCH>.efi. For that it uses
>>      EFI_PXE_BASE_CODE_PROTOCOL directly.
>>
>>      Please see findNetboot() and FetchNetbootimage() in "netboot.c".
>>
>>      (Requiring EFI_PXE_BASE_CODE_PROTOCOL is not unique to shim, see
>>      another boot loader here:
>>      <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/12021>.)
> 
> OK, that makes sense now.  The issue is not (as reported) that iPXE's
> EFI_LOAD_FILE_PROTOCOL does not provide the ability to load arbitrary
> files; no other implementations of EFI_LOAD_FILE_PROTOCOL provide this
> ability, and nothing attempts to use EFI_LOAD_FILE_PROTOCOL in that way
> anyway.  Instead, the issue is that iPXE does not provide
> EFI_PXE_BASE_CODE_PROTOCOL and that other bootloaders assume that this
> protocol will be present.
> 
>> This issue might be fixable in several ways:
>> (a) Rework edk2 to provide EFI_PXE_BASE_CODE_PROTOCOL independently of
>>      EFI_LOAD_FILE_PROTOCOL.
>>
>> (b) Or, implement EFI_PXE_BASE_CODE_PROTOCOL in iPXE, and install it
>>      alongside EFI_LOAD_FILE_PROTOCOL, in efi_snp_probe().
>>
>> (c) Or, drop EFI_LOAD_FILE_PROTOCOL from step 2.1 (dependent on build
>>      time configuration).
>>
>> (d) Or, modify shim.efi, and possibly the other boot loader mentioned in
>>      step 1.5, to use EFI_LOAD_FILE_PROTOCOL. This would also require all
>>      relevant EFI_LOAD_FILE_PROTOCOL implementations to adhere to the
>>      FilePath parameter.
>>
>> Option (c) is by far the least intrusive, and the proposed patch does
>> that.
> 
> The problem is that option (c) also destroys the user's ability to use
> most features of iPXE.  It's a quick hack rather than a solution.

Yes. It would be a quick hack that is disabled by default, but it would
allow downstreams to build iPXE such that it provide SNP only. Useful
for QEMU NICs for which no edk2-internal driver exists. (Which means
"all except virtio-net" -- an e1000 driver is available from Intel, but
it is not redistributable.)

> Option (d) sounds like the best idea, not least because it would allow
> for the use of non-braindead network protocols (i.e. almost anything
> except TFTP).  iPXE could quite easily have code in efi_snp_load_file()
> which would open and autoconfigure the network device, interpret
> FileName as a URI, and thereby allow shim.efi (or others) to download
> files via HTTP, HTTPS, etc.
> 
> Since EDK2 implementations of EFI_LOAD_FILE_PROTOCOL (also) do not
> conform to the UEFI specification, shim.efi should probably retain the
> ability to fall back to EFI_PXE_BASE_CODE_PROTOCOL if
> EFI_LOAD_FILE_PROTOCOL returns EFI_UNSUPPORTED.
> 
> Thoughts?

iPXE: I can't volunteer for the efi_snp_load_file() change.

edk2: since shim would call LoadFile() with BootPolicy=FALSE -- because
the file it would be loading would not be a boot selection --, the
current EFI_UNSUPPORTED branch in EfiPxeLoadFile() would not be taken,
and shim might not fall back to EFI_PXE_BASE_CODE_PROTOCOL. Therefore
FilePath would be necessary to handle here.

shim: I guess I could submit a patch, but I'm unsure if we could get a
binary signed soon enough. (For some definition of "soon".)

Personally I'm fine with TFTP, and the lack of distinguishing iPXE
features, for OVMF guests; keeping it quick & contained is more
important to me.

(After all, that's been the situation before c7c3d839 too. Limiting PXE
boot on OVMF to virtio-net (for which a simple internal driver exists)
might be an option as well.)

I understand that you have the opposite priorities; I'm not trying to
convince you, just giving you my thoughts.

Thanks
Laszlo