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

[Michael Chang]

On Wed, Jan 25, 2017 at 11:19:19AM +0300, Andrei Borzenkov wrote:
> On Wed, Jan 25, 2017 at 11:09 AM, Michael Chang <address@hidden> wrote:
> > On Fri, Jan 20, 2017 at 05:50:56PM +0300, Andrei Borzenkov wrote:
> >> 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.
> >
> > Nothing wrong in providing firmware based approach in addition to grub's 
> > native
> > stack of getting the similar things done.
> 
> You cannot both shut off all layered protocols on physical adapter and
> makes use of these layered protocols. This will need to implement
> alternative networking stack first.

They don't have to be runtime switch to operate at the same time. Make them
distinct modules, and provid a swith for controlling the image being built. We
already have --native switch in grub2-install to incorporate native disk modules
rather than firmware's.

Thanks,
Michael

> 
> > And there's no prioity for what has
> > to be implemented first imho. Occasionally people would prefer firmware 
> > based
> > stack because they need new features it provides that haven't been worked 
> > out
> > in grub, such as the https or fibre networks, or simply to avoid bug from 
> > grub,
> > like the SNP woes among some UEFI box.
> >
> > Thanks,
> > Michael
> >
> >>
> >> > 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
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel