On Tue, 11 Feb 2025 at 10:23, Gerd Hoffmann <kraxel@redhat.com> wrote:
This patch adds a virtual device to qemu which the uefi firmware can use
to store variables. This moves the UEFI variable management from
privileged guest code (managing vars in pflash) to the host. Main
advantage is that the need to have privilege separation in the guest
goes away.
On x86 privileged guest code runs in SMM. It's supported by kvm, but
not liked much by various stakeholders in cloud space due to the
complexity SMM emulation brings.
On arm privileged guest code runs in el3 (aka secure world). This is
not supported by kvm, which is unlikely to change anytime soon given
that even el2 support (nested virt) is being worked on for years and is
not yet in mainline.
The secure counterpart of this would never execute at EL3 on ARM, but
at secure EL1 (or potentially at secure EL2 on more recent CPUs). But
the general point that this is difficult to virtualize stands; I've
contemplated doing something similar to SMM emulation using non-secure
EL1 in a separate VM to provide an execution context that could those
the secure EL1 payload (using standalone MM) but I never found the
time to work on this.
The design idea is to reuse the request serialization protocol edk2 uses
for communication between SMM and non-SMM code, so large chunks of the
edk2 variable driver stack can be used unmodified. Only the driver
which traps into SMM mode must be replaced by a driver which talks to
qemu instead.
I like this approach, but I will note that these protocols are not
standardized: it is basically an EDK2 implementation detail, but this
is fine, given that this targets firmware that is based on EDK2 (or
its derivatives).
Using a single shared communication buffer makes it feasible to
paravirtualize this even under confidential compute scenarios (where
the buffer needs special shared mapping semantics), and I think this
might be useful, even if in principle, the VMM is untrusted in such
scenarios. Paravirtualizing the individual variable services directly
creates a problem here, given that the firmware cannot share mappings
of arbitrary arguments passed via pointers.
For the record, I've already acked the OVMF counterpart of this, and
I've started working on adding support for this to my minimal EFI for
mach-virt [0], which is another scenario (i.e., minimal EFI compatible
firmware for micro VMs) where having this complexity in the VMM is
preferred.