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 <arvidj...@gmail.com> 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 <ken....@hpe.com> 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 > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
