Re: [edk2-devel] [PATCH v10 1/4] OvmfPkg: Add memory acceptance event in AmdSevDxe

["Gerd Hoffmann" <kraxel@redhat.com>]

On Tue, Feb 14, 2023 at 09:28:49AM -0800, Dionna Amalie Glaze wrote:
> >
> > Do you have any pointers on the IVARS service?  Documentation, guest
> > code, host code?
> >
> 
> Agh, I thought for sure there was a public API for VM owners to view
> or change their UEFI variables, but I guess not. It's an
> instance-specific small data store for nonvolatile memory like vTPM
> and UEFI variables. It appears you can only set the variables through
> cloud API at instance creation time. But this is how instances can be
> shut down and brought back up on different machines and/or live
> migrate to other machines and still have access to UEFI variables'
> current values. Host code is all in Google's proprietary VMM,
> Vanadium, but the device backend is really rather simple. The data
> store service though, that's a matter of Cloud Scale Engineering.

The device backend would be a good start (host code being part of the
google vmm is expected ...).

> > Background:  When moving to a SVSM-based setup where the svsm (with
> > vtpm emulation) runs in vmpl0 and the edk2 firmware in vmpl1 we might
> > likewise add a efi variable service to the svsm.
> 
> I thought EFI variables in Qemu were loaded and measured at launch
> (OVMF_VARS.fd).

Yes, that is the current state of affairs.  Variables are fixed and are
measured (launch measurement for SEV, runtime measurement for TDX).  The
variable store lives in RAM and all changes are gone when the guest is
stopped.  So we don't really have persistent EFI variables.

For persistent EFI variables we need to have the variables stored in
some secure place, so the OS can't change -- for example -- secure boot
configuration as it pleases.  In traditional VMs that happens to be SMM
mode.  For SEV-SNP the SVSM could handle this, and we need some protocol
used by SVSM efi variable service and ovmf to talk to each other.  Here
the protocol used by google vmm could eventually be reused.

And possibly the very same protocol could be used to simply run the efi
variable service on the host (for traditional VMs) and ditch SMM mode
then.

> Or is it specifically going to be an SVSM service that attests itself
> with current stored variables, or at least variables that are
> considered important enough to measure?

The variables considered important for secure boot (db etc.) are
measured (by edk2) anyway.

> In any case, persistence in The Cloud (TM) remains a challenge in the
> CC space.

Indeed.  One idea is to hand out some (virtual) flash to the SVSM for
persistent data.  Which would need to be encrypted, and we need to
manage the keys for that.  Not fully sure where we stand here, it's not
my main focus.

take care,
  Gerd