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

["Dionna Glaze" <dionnaglaze@google.com>]

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

> 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). If you want the current values of all uefi variables
in your SVSM attestation report, I think it's probably better to use
the EFI_CC_MEASUREMENT_PROTOCOL, right? 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?

In any case, persistence in The Cloud (TM) remains a challenge in the
CC space. Discussion about what we should do about that should remain
on the coco mailing list. IVARS encrypts data with Google-managed
keys, so it wouldn't be directly applicable to SVSM NVRAM.

> If something usable already exists we don't need to reinvent the wheel.
>

Don't have to tell me twice. In the spirit of OSS collaboration and
product integrity, I think any CC offering's firmware should be public
and verifiably built. I'll keep pushing for that.

> thanks & take care,
>   Gerd
>


-- 
-Dionna Glaze, PhD (she/her)