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

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

On Tue, Jan 07, 2025 at 04:33:27PM +0100, 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.

In the coconut-svsm project there's a likely need for coconut to
provide a UEFI variable store, since we can't store plain text
variables in host context for confidential VMs.

Am I right in thinking that this design approach could be reused
in coconut context with coconut providing the equivalent backend
service, and EDK2 using the same driver to talk to either QEMU
or Coconut's service  ?


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 :|