Re: [RFC 0/2] UEFI-based HTTP Boot

[Andrei Borzenkov]

21.01.2017 06:37, Lin, Keng-Yu пишет:
> 

> The main reason is HTTPS. We've been looking at it for a while.
Recently a few patches of HTTPS Boot were already merge in the EDK2 main
tree (before this, it was in the EDK2-staging tree).
> 
> Please see:
> https://github.com/tianocore/edk2/search?q=tls&type=Commits
> 
> For the software-based implementation, it will be a lot of works to
support this, e.g. interfaces to import or remove certificates, grub has

I do not see how your patch solves this either. UEFI provides no
guarantee that necessary certificates are available in non-volatile
store, so either your patch relies on some third-party software to do it
on every boot or on implementation specific behavior that stores
information permanently. Having hooks in grub to manage this information
would free it from these assumptions and then it does not matter whether
grub will manage it via EFI interface or using own internal implementation.

to depend on GnuTLS or OpenSSL libraries. This means that grub has to
release a new version once GnuTLS or OpenSSL bump their ABIs, etc.

GRUB already reuses libgcrypto. It may be possible to reuse gnutls in
the same way. Sure, it is a lot of work, but then this will also be
available on every platform.

> 
> The ideal picture from us is as below: * For the UEFI firmware v2.4
> and older: use the software-based HTTP
boot. The limitation is this does not include HTTPS.
> 
> * For the UEFI firmware v2.5 and newer: use the UEFI-based HTTP(S)
boot (this RFC patchset). Both HTTP and HTTPS are supported.

This hardly can be used in this form. First, grub is using SNP and
relies on being the only consumer of network device. We already had
quite serious problems when firmware raced with grub for card access.
Your patch spawns off additional protocol(s) that compete with grub.
This cannot work reliably unless we switch grub to MNP.

Second your patch completely bypasses grub event loop and busy waits for
transfer completion. It should hook into general grub net polling
framework.

> 
> I hope this help you and the other maintainers understand the
background of the HTTP(s) Boot patches from us.
> ________________________________________
> From: Andrei Borzenkov <address@hidden>
> Sent: Friday, January 20, 2017 10:50:56 PM
> To: The development of GNU GRUB
> Cc: Lin, Ken (HPS OE-Linux TDC); Chang, Clay (HPS OE-Linux TDC); Lin, 
> Keng-Yu; Knippers, Linda; Ruan, Michael (HPS OE-Linux/VMware TDC)
> Subject: Re: [RFC 0/2] UEFI-based HTTP Boot
> 
> On Fri, Jan 20, 2017 at 4:13 AM, Ken Lin <address@hidden> wrote:
>> This RFC patchset is stacked on the previous HTTP boot patchset:
>> https://lists.gnu.org/archive/html/grub-devel/2016-12/msg00088.html
>> It re-uses some code from it, e.g. the DCHPACK
>> with vendor_class_identifier=HTTPClient.
>>
>> Instead of implementing HTTP and HTTPS boot totally from software,
>> UEFI firmware already defines APIs for HTTP(s).
>> Please check UEFI spec. 2.5 and plus for the detail:
>>
>> 28.6 EFI HTTP Protocols
>>
> 
> Without reviewing patches themselves - we usually prefer to rely on
> firmware as little as possible. We already have HTTP support, so what
> is missing in grub that requires what amounts to full
> re-implementation? Cannot we rather fix our HTTP support instead? This
> will automatically benefit all supported platforms, of which EFI is
> just one.
> 
>> Then why two implementations? For older UEFI firmwares (UEFI 2.4 and older),
>> the HTTP(s) APIs are not available. In the case,
>> Grub can fall back to the software-based implementation.
>> In the first patch of this patchset, grub-core/net/drivers/efi/efihttp.c:76 
>> to 81
>> is the code to query if the HTTP Protocol is supported by the UEFI firmware.
>>
>> This patchset was tested on QEMU+OVMF and it works flawlessly.
>>
>> The main goals of this RFC is to ask for opinions and suggestion to make
>> the first patch modularized as much as possible.
>> In the second patch, there is some codes related TCP re-transmission
>> that need to pass by for the HTTP Boot to work.
>>
>> More details are described in the logs of each patch.
>>
>>
>> Ken Lin (2):
>>   net: add efihttp to do HTTP(S) Boot by UEFI HTTP Protocol
>>   net: workaround to bypass corruption of the efihttp function pointer
>>
>>  grub-core/Makefile.core.def         |   1 +
>>  grub-core/net/bootp.c               |   6 +
>>  grub-core/net/drivers/efi/efihttp.c | 386 
>> ++++++++++++++++++++++++++++++++++++
>>  grub-core/net/drivers/efi/efinet.c  |   1 +
>>  grub-core/net/net.c                 |  39 +++-
>>  include/grub/efi/api.h              |  17 ++
>>  include/grub/efi/http.h             | 221 +++++++++++++++++++++
>>  include/grub/err.h                  |   3 +-
>>  include/grub/net.h                  |   1 +
>>  9 files changed, 672 insertions(+), 3 deletions(-)
>>  create mode 100755 grub-core/net/drivers/efi/efihttp.c
>>  create mode 100755 include/grub/efi/http.h
>>
>> --
>> 2.7.4
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel