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

["Lendacky, Thomas" <thomas.lendacky@amd.com>]

On 2/14/23 11:28, 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.
> 
>> 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

The variables are not encrypted and not measured at launch because they 
need to be modified and stored on the host side.

You can choose to use a single vars/code file, which keeps the variables 
in memory, but you then lose any changes made to them upon VM termination.

Thanks,
Tom

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