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

[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 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.

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.

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