Re: [PATCH 00/16] hw/uefi: add uefi variable service

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Nov 21, 2023 at 04:58:44PM +0100, Laszlo Ersek wrote:
> On 11/20/23 17:50, Gerd Hoffmann wrote:
> > On Mon, Nov 20, 2023 at 12:53:45PM +0100, Alexander Graf wrote:
> >> Hey Gerd!
> >>
> >> On 15.11.23 16:12, Gerd Hoffmann 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 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'm not sure I like the split :). If we cut things off at the SMM
> >> communication layer, we still have a lot of code inside the Runtime Services
> >> (RTS) code that is edk2 specific which means we're tying ourselves tightly
> >> to the edk2 data format.
> > 
> > Which data format?
> > 
> > Request serialization format?  Yes.  I can't see what is wrong with
> > that.
> 
> ... I can't even see what's wrong with *that*. Realistically /
> practically, I think only edk2 has been considered as guest UEFI
> firmware for QEMU/KVM virtual machines, as far as upstream projects go.
> It's certainly edk2 that's bundled with QEMU.
> 
> My understanding is that firmware is just considered a part of the
> virtualization platform, so teaching edk2 specifics to QEMU doesn't seem
> wrong. (As long as we have the personpower to maintain interoperability.)
> 
> > We need one anyway, and I don't see why inventing a new one is
> > any better than the one we already have in edk2.
> > 
> > Variable storage format?  Nope, that is not the case.  The variable
> > driver supports a cache, which I think is a read-only mapping of the
> > variable store, so using that might imply we have to use edk2 storage
> > format.  Didn't check in detail through.  The cache is optional, can be
> > disabled at compile time using PcdEnableVariableRuntimeCache=FALSE, and
> > I intentionally do not use the cache feature, exactly to avoid unwanted
> > constrains to the host side implementation.
> > 
> >> It also means we can not easily expose UEFI
> >> variables that QEMU owns,
> > 
> > Qemu owning variables should be no problem.  Adding monitor commands to
> > read/write UEFI variables should be possible too.
> 
> This patch set is actually an improvement towards QEMU-owned variables.
> Right now, all variables are internal to the guest; QEMU only has a
> pflash-level view.

To throw confidental computing into the mix....

Right now for SEV-SNP/TDX, the EDK2 builds are stateless so that
variables are thrown away at poweroff.

Long term though there's interest in having the ability to (optionally)
offer persistence of variables to confidential computing too.

The key issue is that the host QEMU is not trusted so it would not be
viable to let QEMU receive the variables in plain text.

One option I've illustrated before is that have SVSM (or equiv)
expose an encrypted storage service to EDK2. Given the proposed EDK2
side protocol/modifications for variable storage, I wonder if it is
viable for SVSM (or equiv) to replace QEMU in providing the backend
storage impl ?  IOW, host QEMU would expose a pflash to the guest,
to which SVSM would apply full disk encryption, and then store the
EFI variables in it

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|