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

[Gerd Hoffmann]

  Hi,

> 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

Yes.  IIRC (it's been a while I've looked at the spec) the SVSM can
request that access to specific pages trap, so it could use that to 
emulate the mmio/sysbus variant of the device.  Not sure if that could
work for io/isa too.  Another option would be to add a third interface
variant which uses SVSM service calls.

And one advantage of a rust implementation would be that integrating
with coconut-svsm (which is written in rust too) might be easier.  On
the other hand the SVSM is a very different environment, the rust stdlib
is not available for example, and the way persistence is implemented
will probably look very different too.  Another difference is crypto
support, qemu uses nettle / gnutls whereas svsm will probably use
openssl.  So not sure how big the opportunity to share the code between
qemu and svsm on the backend side actually is.

take care,
  Gerd