[edk2-devel] Initial PXE boot over IPv6

Fri Mar 27 23:01:59 UTC 2020

Hello Per,

unfortunately, due to the spectacularly broken threading in this
discussion, I have to reconstruct the history manually first:

On Mar 27, 2020, at 8:51 AM, per_sundstrom via Groups.Io
<per_sundstrom=yahoo.com at groups.io> wrote:

> I want to exclusively use PXE/IPv6 when deploying a set of physical
> machines with some QEMU/KVM virtual machines on top.
>
> So far, the only [hacky] way I have managed to do this is to:
> 1) Bring up a VM with OVMF
> 2) Set the wanted boot-order with PXE over IPv6 at the top
> 3) Save this to the NVRAM
> 4) Repete the above for a set of VMs with different MAC addresse
> 5) Keep these NVRAMs as "canned" templates (with associated fixed
>    MACs)
> 4) Later use one of these NVRAM as a template for VMs with the
>    associated MAC
>
> Obviously this does not scale to hundreds of VMs
>
> Reading through the code is seems that it might be possible to disable
> PXE over IPv4 with the PCD variable "IPv4PXESupport" = <one byte
> binary zero>.
>
> I have tried with
>     <qemu:arg value='-fw_cfg'/>
>     <qemu:arg value='opt/ovmf/X-PcdIPv4PXESupport,file=/var/lib/libvirt/qemu/nvram/zero'/>
>
> where the file is a one byte binary zero and I have verified that it
> shows up in /sys/firmware/qemu_fw_cfg.
> linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # ls opt/ovmf/X-PcdIPv4PXESupport/
> key  name  raw size
> linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # cat opt/ovmf/X-PcdIPv4PXESupport/size
> 1
> linux-u7u9:/sys/firmware/qemu_fw_cfg/by_name # od -b opt/ovmf/X-PcdIPv4PXESupport/raw
> 0000000 000
> Is this something that should work, or is this variable compiled in ?
> Are there other ways of acomplishing what I try to do ?

On 03/27/20 18:05, Andrew Fish via Groups.Io wrote:

> PCD's are a Platform Configuration Database that is used in the edk2.
> Values can be compiled in, patched in binaries, or looked up
> dynamically in a database. The idea is the consuming code, like the
> UefiPxeBcDxe driver, codes stays the same and the platform sets the
> mechanism that is used. It looks like value you care about is
> resolving to a compiled in constant.
>
> If you want to change the value in the build go to
> OvmfPkg/OvmfPkgX64.dsc (or the platform build DSC file you are using)
> under the [PcdsFixedAtBuild] section add this line:
>   gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0
>
> This PCD value is defined here: NetworkPkg/NetworkPkg.dec
> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> ...
>   ## IPv4 PXE support
>   # 0x01 = PXE Enabled
>   # 0x00 = PXE Disabled
>   gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0x01|UINT8|0x10000009
>
> The list of types define (DEClare) the legal PCD types and the default
> value. Adding the info to the OVMF DSC file lets the platform build
> control the PCD type and the default value.
>
> Feel free to file a bugzilla and ask for a command line build option
> to control this feature.

On 03/27/20 18:38, per_sundstrom via Groups.Io wrote:

> Thanks for the quick reply.
> I sort of suspected that it was compiled in :-(
>
> How hard would it be to have it configured through fw_cfg ?
> We are on a supported distro and are not allowed homebrewed binaries.
>
> And, [more importantly] are there any other ways of persuading OVMF to
> boot from IPv6 without manually updating the boot order ?

Please file a TianoCore Feature Request here:

  https://bugzilla.tianocore.org/

Upon reading this thread, I was initially *very* opposed to exposing
this PCD via fw_cfg. Every PCD we expose like that ends up being a
"contract" between users of OVMF and the internals of edk2, even if we
carefully use the "X-" prefix ("experimental").

In particular, you seem to want to use this config knob in a production
environment -- I'm sure you wouldn't appreciate if,  after an OVMF
package upgrade, the knob simply disappeared, and we'd justify that with
"we told you so, the name was X-whatever!".

... However, based on
<https://bugzilla.tianocore.org/show_bug.cgi?id=1695>, and the
corresponding commit b29e6365c37f ("NetworkPkg/UefiPxeBcDxe:Add two PCD
to control PXE.", 2019-04-22), exposing this particular PCD feels a tiny
bit safer. It appears to be exposed through HII on some (undisclosed)
physical platforms as of this moment. That suggests the PCD is here to
stay in the long run (also I note the DEC file permits dynamic access at
once).

So I guess we could investigate something similar to commit ab081a50e565
("OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command
line", 2015-09-15). Hence my suggestion to file a Feature Request.

I'm not happy about this (this control knob is coarse-grained, and it
doesn't cover other aspects -- what about ordering HTTP(S) boot versus
PXE? what about ordering IPv4 vs. IPv6 in HTTPS?), but given that the
PCD exists, and is arguably exposed on physical platforms via HII, I
guess I won't program myself into a corner when exposing the PCD through
fw_cfg. :/

No promises. I might be able to look into it, as time allows.

And no, I don't have any other suggestion, especially if the feature is
desired for virtual machines that already have Secure Boot enabled when
they PXE-boot.

BTW, the following QEMU syntax exists too:

  -fw_cfg [name=]<item_name>,string=<string>

That is, simple string content can be placed into externally provided
fw_cfg files directly on the QEMU cmdline; no host-side file is needed.
See section "Externally Provided Items" in "docs/specs/fw_cfg.txt" in
the QEMU tree. (Mentioning this in case we end up with a "y/n" user
interface or some such.)

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#56519): https://edk2.groups.io/g/devel/message/56519
Mute This Topic: https://groups.io/mt/72590544/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-