Re: Runtime configuration methods for OVMF/AAVMF?

Laszlo Ersek

On 03/10/21 16:16, Laszlo Ersek wrote:

One telling example is "efibootmgr". It lets you tweak some stuff (boot
order, boot options, Timeout variable) on physical platforms at least.
However, when using OVMF, those settings are overridden dynamically on
every boot, when using the "bootindex" device properties, and/or the
"-boot menu=on" / "-boot splash-time=N" options.
two other examples (not an exhaustive list by far), for fw_cfg-based

- The cipher suites, and the CA certificates, that are to be trusted by
the firmware for UEFI HTTPS Boot (TLS), are propagated from the host
side to the guest via fw_cfg.

The platform-independent TLS machinery in edk2 uses a UEFI variable for
each of these two aspects (two variables in total). And, at least for
the CA certificates, the base assumption is that the variable is
non-volatile, and can be configured through the Setup TUI (adding
trusted CA certs one by one).

However, when using OVMF, both variables are deleted and re-created as
non-volatile, and they are populated from fw_cfg, from the host side.
(See "OvmfPkg/Library/TlsAuthConfigLib".) In turn, on the host side,
p11-kit and QEMU features were implemented, in order to generate /
expose the necessary content in the right format for OVMF.

- whether IPv4 and/or IPv6 is attempted in UEFI PXE boot is also
controlled via fw_cfg.

... Over the years I've observed a strong discrepancy between user
wishes for OVMF configurability. Some users want to control behaviors
from the inside (that is, running from within the guest), exluding even
the OVMF Setup TUI from that -- basically an "efibootmgr-like OS
utility. Other users want to control behaviors from as far outside as
possible (a management application layered even higher than libvirt, for
example). Yet other users feel OVMF should be as close to physical
platforms as possible, and everything that's configurable should be
exposed via the setup TUI (example: the preferred boot-time graphics
resolution; it was really difficult (and over-engineered) to implement
that with HII). Finally, the Confidential (remote-attested, encrypted)
Boot scenario requires OVMF to ignore as many firmware settings as
possible, from both the guest side and the host side. One can only hope
that users realize at some point that it's impossible to satisfy all
these desires at the same time. We've been creating dedicated OVMF
platforms for some of these (e.g. new DSC / FDF files, and a new
PlatformBootManagerLib instance, for the attested boot scenario), but it
remains a struggle.


Join to automatically receive all group messages.