All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Patrick Wildt <patrick@blueri.se>,
	Alexander Graf <agraf@csgraf.de>,
	u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	GRUB development mailing list <grub-devel@gnu.org>,
	pjones@redhat.com
Subject: Re: EFI_PXE_BASE_CODE_PROTOCOL
Date: Tue, 6 Aug 2019 09:44:14 +0100	[thread overview]
Message-ID: <20190806084414.GD25813@bivouac.eciton.net> (raw)
In-Reply-To: <3b958976-1801-c3cc-196d-606293a06938@gmx.de>

+Peter Jones (sorry Peter)

On Tue, Aug 06, 2019 at 08:34:58AM +0200, Heinrich Schuchardt wrote:
> iPXE uses the EFI simple network protocol to execute DHCP.

OK.

> Can GRUB already do the same when the EFI_PXE_BASE_CODE_PROTOCOL is not
> present?

Yes. As of very recently (proper* DHCP support was only merged in
March 2019, so is included in 2.04 release, prior to that it
technically performed BOOTP).

SNP means you do your own networking - it gives you access to the raw
(usually) Ethernet packets.

* proper as in "it now conceptually does the correct thing", not as in
  "I have extensively tested this".

> What I do not understand about GRUB's grub_net_configure_by_dhcp_ack()
> is that it silently assumes IPv4 being used without even checking. This
> contradicts the definition of the PXE base code protocol in the UEFI
> standard:

Well, it would not surprise me if this function predates GRUB's UEFI
support.

It actually gets even slightly messier when you look at what GRUB does
when netbooting itself; it starts out using MNP (and hence IP
addresses assigned by UEFI) to load its modules, switching to SNP once
it loads efinet.mod.

> EFI_PXE_BASE_CODE_PACKET DhcpAck is a union:
> 
> typedef union {
>  UINT8                             Raw[1472];
>  EFI_PXE_BASE_CODE_DHCPV4_PACKET   Dhcpv4;
>  EFI_PXE_BASE_CODE_DHCPV6_PACKET   Dhcpv6;
> } EFI_PXE_BASE_CODE_PACKET;
> 
> Should the check be done in grub_efi_net_config_real()?

Possibly. I've cc:d Peter since he's the last person I know who took a
proper look at this.

Certainly, it would be useful if you could raise a bug on Savannah on
the ipv4 assumption.

Best Regards,

Leif


WARNING: multiple messages have this Message-ID (diff)
From: Leif Lindholm <leif.lindholm@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL
Date: Tue, 6 Aug 2019 09:44:14 +0100	[thread overview]
Message-ID: <20190806084414.GD25813@bivouac.eciton.net> (raw)
In-Reply-To: <3b958976-1801-c3cc-196d-606293a06938@gmx.de>

+Peter Jones (sorry Peter)

On Tue, Aug 06, 2019 at 08:34:58AM +0200, Heinrich Schuchardt wrote:
> iPXE uses the EFI simple network protocol to execute DHCP.

OK.

> Can GRUB already do the same when the EFI_PXE_BASE_CODE_PROTOCOL is not
> present?

Yes. As of very recently (proper* DHCP support was only merged in
March 2019, so is included in 2.04 release, prior to that it
technically performed BOOTP).

SNP means you do your own networking - it gives you access to the raw
(usually) Ethernet packets.

* proper as in "it now conceptually does the correct thing", not as in
  "I have extensively tested this".

> What I do not understand about GRUB's grub_net_configure_by_dhcp_ack()
> is that it silently assumes IPv4 being used without even checking. This
> contradicts the definition of the PXE base code protocol in the UEFI
> standard:

Well, it would not surprise me if this function predates GRUB's UEFI
support.

It actually gets even slightly messier when you look at what GRUB does
when netbooting itself; it starts out using MNP (and hence IP
addresses assigned by UEFI) to load its modules, switching to SNP once
it loads efinet.mod.

> EFI_PXE_BASE_CODE_PACKET DhcpAck is a union:
> 
> typedef union {
>  UINT8                             Raw[1472];
>  EFI_PXE_BASE_CODE_DHCPV4_PACKET   Dhcpv4;
>  EFI_PXE_BASE_CODE_DHCPV6_PACKET   Dhcpv6;
> } EFI_PXE_BASE_CODE_PACKET;
> 
> Should the check be done in grub_efi_net_config_real()?

Possibly. I've cc:d Peter since he's the last person I know who took a
proper look at this.

Certainly, it would be useful if you could raise a bug on Savannah on
the ipv4 assumption.

Best Regards,

Leif

  reply	other threads:[~2019-08-06  8:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 12:24 [U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag Patrick Wildt
2018-03-27 16:05 ` Heinrich Schuchardt
2018-12-02 21:21   ` Alexander Graf
2019-01-31 14:25     ` Patrick Wildt
2019-01-31 14:31       ` Alexander Graf
2019-01-31 14:54         ` Patrick Wildt
2019-01-31 18:29           ` Heinrich Schuchardt
2019-02-04 16:43             ` Patrick Wildt
2019-02-04 17:28               ` Heinrich Schuchardt
2019-04-10  9:20             ` Patrick Wildt
2019-04-10  9:24               ` Patrick Wildt
2019-08-02 19:26                 ` Patrick Wildt
2019-08-04 11:52                   ` Heinrich Schuchardt
2019-08-05 20:08                     ` [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL Heinrich Schuchardt
2019-08-06  6:34                       ` EFI_PXE_BASE_CODE_PROTOCOL Heinrich Schuchardt
2019-08-06  6:34                         ` [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL Heinrich Schuchardt
2019-08-06  8:44                         ` Leif Lindholm [this message]
2019-08-06  8:44                           ` Leif Lindholm
2019-08-06 17:02                           ` EFI_PXE_BASE_CODE_PROTOCOL Peter Jones
2019-08-06 17:02                             ` [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL Peter Jones
2019-08-06 18:52                             ` EFI_PXE_BASE_CODE_PROTOCOL Heinrich Schuchardt
2019-08-06 18:52                               ` [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL Heinrich Schuchardt
2019-08-06 19:35                               ` EFI_PXE_BASE_CODE_PROTOCOL Leif Lindholm
2019-08-06 19:35                                 ` [U-Boot] EFI_PXE_BASE_CODE_PROTOCOL Leif Lindholm
2019-08-06 17:49                     ` [U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag Heinrich Schuchardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190806084414.GD25813@bivouac.eciton.net \
    --to=leif.lindholm@linaro.org \
    --cc=agraf@csgraf.de \
    --cc=grub-devel@gnu.org \
    --cc=patrick@blueri.se \
    --cc=pjones@redhat.com \
    --cc=sjg@chromium.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.