[PATCH v2 1/3] net: Get pxe config file from dhcp option 209

[Tom Rini]

On Thu, Nov 09, 2023 at 02:35:40PM -0700, Heinrich Schuchardt wrote:
> 
> 
> Am 9. November 2023 14:04:40 GMT-07:00 schrieb Tom Rini <trini at konsulko.com>:
> >On Wed, Nov 08, 2023 at 12:24:24PM +0000, Peter Robinson wrote:
> >> > > > > > > Allow dhcp server pass pxe config file full path by using option 209
> >> > > > > > >
> >> > > > > > > Signed-off-by: Sean Edmond <seanedmond at microsoft.com>
> >> > > > > > > ---
> >> > > > > > >   cmd/Kconfig |  4 ++++
> >> > > > > > >   cmd/pxe.c   | 10 ++++++++++
> >> > > > > > >   net/bootp.c | 21 +++++++++++++++++++++
> >> > > > > > >   3 files changed, 35 insertions(+)
> >> > > > > > >
> >> > > > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> >> > > > > > > index 5bc0a92d57..adbb1a6187 100644
> >> > > > > > > --- a/cmd/Kconfig
> >> > > > > > > +++ b/cmd/Kconfig
> >> > > > > > > @@ -1826,6 +1826,10 @@ config BOOTP_PXE_CLIENTARCH
> >> > > > > > >       default 0x15 if ARM
> >> > > > > > >       default 0x0 if X86
> >> > > > > > >
> >> > > > > > > +config BOOTP_PXE_DHCP_OPTION
> >> > > > > > > +    bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
> >> > > > > > > +    depends on BOOTP_PXE
> >> > > > > >
> >> > > > > > Why should this be disabled by default?
> >> > > > > >
> >> > > > > > Do we really want a separate config variable?
> >> > > > > >
> >> > > > > I expect most won't use this option to get the file path (they'll use
> >> > > > > the default paths as per the PXE specification).  It makes more sense
> >> > > > > for me to keep it optional, like many of the other options?
> >> > > >
> >> > > > RFC 5701 seems to require this option. Hence we should make it default
> >> > > > yes. Boards that have a build size issue can opt out.
> >> > >
> >> > > The PXELINUX specification
> >> > > (https://wiki.syslinux.org/wiki/index.php?title=PXELINUX) doesn't state that
> >> > > option 209 is required. In the abense of option 209, PXELINUX will try the
> >> > > following default configuration files (this example is provided on the wiki
> >> > > link):
> >> > >  /mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
> >> > >  /mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
> >> > >  /mybootdir/pxelinux.cfg/C0A8025B
> >> > >  /mybootdir/pxelinux.cfg/C0A8025
> >> > >  /mybootdir/pxelinux.cfg/C0A802
> >> > >  /mybootdir/pxelinux.cfg/C0A80
> >> > >  /mybootdir/pxelinux.cfg/C0A8
> >> > >  /mybootdir/pxelinux.cfg/C0A
> >> > >  /mybootdir/pxelinux.cfg/C0
> >> > >  /mybootdir/pxelinux.cfg/C
> >> > >  /mybootdir/pxelinux.cfg/default
> >> > >
> >> > > If 209 is requested/provided it tries the provided "config file" before the
> >> > > default paths.  RFC 5071 should be seen as an extension for PXELINUX (not a
> >> > > requirement).  RFC 5071 only states "The Config File Option MUST be supplied
> >> > > by the DHCP server if it appears on the Parameter Request List".
> >> >
> >> > We also want to be careful about overall size growth on common options,
> >> > even if someone can opt-out. Those are usually last-ditch stop-gaps and
> >> > it's better to make sure we really need functionality X/Y/Z by default,
> >> > for everyone. Especially with all of the work going on to make HTTP(s)
> >> > based network installs a viable option, how much more do we want to
> >> > change the PXE case, for everyone. I'm personally somewhat looking for
> >> > the use case to be well defined for a "this must be default". Network
> >> > provisioning is a thing, yes, but for whom/what, and in turn how broadly
> >> > do we need this to be in the vast majority of our boards (since it would
> >> > come in via BOOT*DEFAULTS or DISTRO_DEFAULTS).
> >> 
> >> If PXE is being enabled I think it's useful in that it means the PXE
> >> client can be largely stateless because it can all be provided by
> >> central netowork configs as opposed to either hard wiring it into
> >> firmware or someone having to manually set them. This is likely also
> >> useful from the PoV less reasons to have a shell if it can be dealt
> >> with in code.
> >> 
> >> From the PoV of defaults, with or without HTTP boot, I suspect it
> >> probably makes sense to review whether PXE as a whole is enabled by
> >> default. That said a number of silicon vendors are actually actively
> >> removing PXE from their reference FW in favour of HTTP Boot due to
> >> security and a number of other reasons (easier for firewalls,
> >> caching/CDN, edge use cases outside of the data centre).
> >
> >I guess I don't understand how frequent a use case PXE boot is, on the
> >types of platforms U-Boot is usually found on. Clearly, some people and
> >usecases use it. But I also think part of why it's default enabled
> >within the "distro" frameworks is because initially we didn't have
> >"parse extlinux.conf" entirely split from "do pxeboot" as the conf file
> >parsing started there. I guess just something to evaluate down the road,
> >and perhaps make it a regular thing to evaluate defaults and provide
> >some notice when we might disable features.
> >
> 
> For security reason it is preferable to disable PXE boot if it is not really needed. So default no would make sense.

We can evaluate things and make sure everyone knows when changes are
coming, for the future. We've been enabling it by default for years and
"for security" isn't a great reason. It's one of the last targets tried
and I would argue if there's malicious actors on your network serving up
bootable payloads to random devices, there's bigger problems afoot.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231109/e7de82fb/attachment.sig>