[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/2] UEFI-based HTTP Boot
Re: [RFC 0/2] UEFI-based HTTP Boot
Sat, 21 Jan 2017 03:37:46 +0000
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:
> 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
> 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
> Grub-devel mailing list